Comments on architecture document through Sect. 3 (long)

["Mark Day" <markday@cisco.com>]

These are all based on draft-green-cdnp-gen-arch-01.txt

I quite like the way that the document is shaping up overall.  The large
number of comments is due to going through the document very carefully and
trying to approach it as though I'm unfamiliar with the area.  I'm also
sending a bunch of typo/spelling/phrasing comments to the design team only.

Overall structure:

It looks to me like it would be a good idea to separate what we believe we
know from what we think we have to solve. Can we think about splitting this
draft into an abstract architecture document and a new document containing
problems to be solved?  They could follow the same structure, but then the
reader wouldn't lurch back and forth between known and unknown.

What is our accepted usage of "system" vs. "SYSTEM"?  The document has
"DISTRIBUTION SYSTEM" but "DISTRIBUTION PEERING system", which seems weird.

Abstract:

Is the definition of the problem correct?  I thought there was some
sentiment at the Oct3 meeting for defining the "interface to a CDN", whether
that interface was then used by content publishers or other CDNs.

The explanation of the term "peering" needs to appear before the use of it.

Section 1:

Shouldn't use CAPITALS before explaining their use and their origin in the
model document.

Scale and reach are undefined. Do those need to be part of the model, or
just explained informally here?

> it involves the peering of content delivery
> according to semantically rich application policies.

I don't really know what's meant here. It reads like marketing literature
unless there is some more information (like examples or citations).

The paragraph starting "The context of "peering"" probably needs to be a
section on its own, addressing the subject of "What is Peering?" or "Is this
peering?" or similar. That discussion probably needs to move to the model
document. I see the following concepts to be introduced, distinguished, and
related to our work with CDNs:
1. Dictionary definition of peer
2. Peering as synonym for "speaking BGP"
3. Peering as contrast for "purchasing transit"

The term URI is in all caps but not in the model. Should mention it as an
exception to the rule that "terms in all caps are in the model document."

Section 2:

Need to explain what an overlay network is.  It's good to talk about the
relationship administrative domains, ASs, and overlay networks, but the
paragraph doesn't actually define these or their relationship clearly.

> 1. The ORIGIN publishes content into the DISTRIBUTION SYSTEM.
> This process includes both the delegation of URI name space
> to the DIRECTION PEERING system and delegation of delivery to
> the DISTRIBUTION PEERING system.

Since the diagram doesn't include the DISTRIBUTION SYSTEM, it's hard to
understand its relationship to the DIRECTION PEERING system and the
DISTRIBUTION PEERING system. Do we need some diagrams here showing that the
DIRECTION PEERING system is the interconnection of two DIRECTION SYSTEMs and
likewise for DISTRIBUTION?

It's also probably useful to clarify that content might not be moving
anywhere at this "publication" step -- it could be pulled on demand later.

> 3.  The CLIENT requests content from a SURROGATE.

This can't be right. The CLIENT doesn't initially know about a SURROGATE in
a typical CDN, it gets redirected there. The CLIENT's model is that it's
interacting with either the ORIGIN or with a vanilla DNS system.

There is a style of peering that involves the SURROGATE redirecting to
another CDN's SURROGATE, but it's not the only style we want to describe at
the abstract level.

> Additionally, it is important to note that the core elements can be
> provided by independent administrative domains [2] so long as they
> have authorized peering relationships (i.e. affiliations) between
> themselves.

I don't understand what this is attempting to allow or prevent. Perhaps a
little more explanation would help.

> The DIRECTION PEERING system represents the request routing function
> of the CDN peering system.  It is responsible for binding CLIENTs to
> peered CDNs for the delivery of content.

I would like to combine these, since I don't think the first sentence adds
much. Do we understand what it means to "bind" a CLIENT to a CDN?  I think
it needs a little more definition somewhere.

> It has a dependency upon
> the DISTRIBUTION PEERING system for content location information
> within the peered CDNs.

I'm not sure how to reconcile this with the claim in Section 2 that the
DISTRIBUTION PEERING system doesn't really need to be there.

> Such redirection is
> accomplished through a variety of connection hand-off mechanisms
> including but not limited to DNS [3], HTTP [8], RTSP [6], etc
> redirection.

It seems that we need a crisper definition of what is and is not a
redirection mechanism.  I don't think "connection hand-off" clarifies much.
If we had such a definition, then it would be fine to give an open-ended
list of examples. But the reader previously unfamiliar with this space won't
see much similarity between DNS, HTTP, and RTSP.

The term "requests a URI" is convenient but technically incorrect. Probably
before the document uses it, we should clarify that we are using it to mean
"requesting the resource identified by a URI." (Or whatever the correct
phrase would be, if I'm also wrong).