[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Distribution Draft
Nalin,
Sorry for the delay in responding. Responses/comments inserted below.
--Lisa
nalin@nortelnetworks.com writes:
>
> A few comments/suggestions on this preliminary draft.
>
> a. The draft should specifically include seperate sections capturing
> requirements placed by the Distribution Peering System on the Request
> Routing System (RRS) and Accounting System (AS)
>
I have added some text along these lines, but want to avoid duplicating
information that is covered in the other documents. I just sent the updated
version to the mailing list.
Please be more specific on what info you think is falling through the
cracks.
> b. Section 2
> To support the N:1 and 1:N Content Distribution: Content Source
> capabilities, are some minimum set of capabilities assumed or required from
> the underlying network or the CPGs?
>
I think we are converging on protocols that would amount to one CDN opening
a channel to receive info from a peer (e.g. the Content Destination may be
required to join an invalidation channel specified by the Content Source
while providing distribution services for that Content Source). However,
I want to avoid saying this requires specific, say multicasting,
capabilities. Instead, at least at this point, the *requirement* should stand
at being scalable to the extent of enabling Internet-wide peering
relationships.
> b. Section 2
> ".... Routing services, the CPGs for Distribution-only CDNs MUST support
> Accounting and Request Routing peering protocols, in addition to
> Distribution Peering protocols....... "
>
> This is inconsistent with what is captured in the scenario's document.
> Although I agree with what captured in this draft, I would like it to state
> why this requirement is being enforced with examples.
>
Although this is not spelled out in the scenarios doc, I didn't think it was
inconsistent. In the scenarios doc, Fig2 shows 2 CDNs whose
CPGs are sending accounting and RRS info back to ORG A's CPG since ORG A is
providing accounting and direction functions. In Fig3, ORG A provides only
accounting, so CDN-A and CDN-B's CPGs forward this info to ORG A; but since
ORG A is not providing RRS, (CDN A and CDN B are peered for RRS and
distribution) RRS info flows between the CPGs of CDN A and CDN B, but not
to ORG-A.
> c. Section 2
> ".......That is, the CPG of a
> Distribution-only CDN must interface with the CPGs of the Accounting
> and Request Routing CDNs, and optionally, other Distribution
> CDNs...... "
>
> I am assuming what you mean here is within a CPG, the DPS, RRS and AS must
> interface, while between CPGs, it are the the DPS system that interface.
>
No, I consider the DPS, RRS and AS peering that we are defining to be between
CPGs. However, routing (directional) and accounting information can be
generated by a CPG of a Distribution CDN. And, if the Distribution CDN
is providing only Distribution services for some content set, then (for that
content set, it will send the accounting and RRS info to some other entity
(via it's CPG -- since the CPG is the bridge between intra-CDN and inter-CDN).
So, using this (below) figure from the scenarios document. The links marked
with an "X" are intra-cdn and are not addressed in the DPS, RRS or AS
requirements documents. But, on the links marked by d*, r* and a*, the CPGs
will exchange info and the requirements for protocols used to exchange
this info is being defined in the DPS, RRS, and AS documents, respectively.
However, that is not to say these must be three distinct protocols,
sessions, ..., just that d* requirements are directly tied to distribution
(r* tied to RR,a* tied to accounting).
+--------------+
| ORG A |
|..............| X +--------------+
| DIRECTION |<===>| |
|..............| | CDN |
| ACCOUNTING |<===>| PEERING |
+--------------+ X | GATEWAY |
| |
+--------------+
^| ^| ^| ^|
// // \\ \\
a*// //r* a*\\ \\r*
+--------------+ // // \\ \\ +--------------+
| CDN A | |v |v |v |v | CDN B |
|..............| X +---------+ +---------+ X |..............|
| DIRECTION |<=>| | | |<=>| DIRECTION |
|..............| X | CDN | d* | CDN | X |..............|
| DISTRIBUTION |<=>| PEERING |<==>| PEERING |<=>| DISTRIBUTION |
|..............| X | GATEWAY | | GATEWAY | X |..............|
| ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
|--------------| +---------+ +---------+ +--------------+
X| ^ X | ^
v | v |
+--------------+ +--------------+
| SURROGATES | | SURROGATES |
+--------------+ +--------------+
> d. Section 2.1
> This section is confusing! It is more tied to scenario's and RRS as opposed
> to DPS. Can you please state the original intent of this section.
>
The intent of this section was to describe the cases where a distribution system
is (En-route Model) on the communications path between the client and source
and where the distribution system is not (Redirected Model) on the
communications path between client and source. It is definitely related to
the RRS since the RRS determines how the client is directed to the distribution
system.
The point is, Access Providers currently offer a form of best-effort distribution
services (caching). The protocols we define should allow such en-route
distribution systems to provide services beyond best-effort without requiring
they follow the DNS-style redirection used by traditional CDNs. What difference
does this make to the distribution peering system? Well, instead of requiring
the distribution system establish some distinct distribution advertising channel,
why not also allow distribution systems to specify they offer services when
the content is being retrieved as a caching proxy normally does. Maybe the only
services the Content Source would accept this way are accounting (at least
until it determines how much content is being distributed/delivered
to which of it's clients), or maybe it would allow distribution and delivery
if the Content Destination joined, say an invalidation channel. Probably,
IMO, the Content Source has negotiated a settlement with this Access Provider
through some offline contract, and this is a way for the Access Provider
to let the Content Source know it is getting some of that preferential
treatment.
I've significantly revised this area in the draft, please let me know if
it's still confusing.
> e. Section 3.1
>
> For the 3 components of the DPS sepcified, you should list common base
> functionality and then any deltas.
I don't understand the above statement.
> Please add to list what underlying
> transport mechanism is: TCP, UDP...etc
>
> f. Section 3.4
> Are there any plans to include status messages
>
If you mean messages from the distribution CDN indicating the status of
the content for which this distribution CDN has agreed to provide
distribution and delivery status, then the answer is not via the
distribution peering communications. That is, if RR services are not
provided by a Distribution CDN, then the Distribution CDN will send
messages to the RRS to indicate it is able (or not able) to service
requests for accepted content. If Accounting services are not
provided by a Distribution CDN, then the Distribution CDN will send
access info to the Accounting System.
If you mean messages from the Content Source on the status of
content (i.e., the new expiration time for this object is...),
then, yes.
> g. Section 4.1
> "...... 1. The Content Source will make a decision to request content
> distribution services from a Content Destination. This decision
> may have been preceded by one or more Content Destinations
> sending distribution capabilities advertisements to the Content
> Source, negotiation of an offline contractual agreement, or some
> combination. ...."
>
> The draft should be clear of the peering arrangement type: Out-of-band or
> through advrtisments. (i.e list the options clearly)
>
Do you mean the draft or the protocol (i.e., the request to inject content)?
If you meant the draft, then I disagree, I think this is between the Content
Source and Destination (advertisements may be okay, advertisements with certain
info may be required, an offline contractual agreement may be required, ...).
If you meant the protocol, I think this is covered. Specifically, the request
to inject content may include a profile id. This identifier is understood
by the Content Source and Destination, including the agreement type.
> h. Section 4.2
> Should include the base underlying protocol and attain consistency with RRS
> and AS.
>
I don't understand the 'attain consistency...' part of this statement. If you
meant consistency in the naming conventions used, please state the instances.
If you meant on the base protocol, I don't understand why this is a requirement.
> i: Section 4.2
> ".... Protocols must support the ability to optionally conduct
> authenticated and/or encrypted exchanges. ...."
>
> I am bit suprised by the optional statement. I would like to hear from the
> service providers on this one!
>
Why isn't it reasonable that a content provider may pay for distribution services
of, say images, but not care if anyone accessed these images? In other words,
certain content is not of "value", but the distribution (i.e., customer
service) is.
> j. Section 4.4
> "....... 4. The CPG of a Content Destination MAY support advertising.
> That
> is, real-time advertisement of distribution capabilities are
> not be required to establish a Distribution Peering
> arrangement. Distribution capabilities may be specified
> offline (e.g., as part of contractual negotiations between the
> parties) or through some, UDDI for example, web based service
> exchange. ....."
>
> Can I assume there are 2 parts: Policy configuration (done offline),
> Advertisments ? This paragraph needs to be cleaned up.
>
Is the following more clear?
The CPG of a Content Destination MAY support distribution capabilities
Advertising. That is, a Content Source may not require real-time
advertisement of distribution capabilities in order to establish a
Distribution Peering arrangement. Distribution capabilities may be
communicated via Advertisements or some other agreed upon mechanism
such as an offline contract negotiated between the parties.
> k. Section 4.4
> "....
> Capacity: The storage capacity that the CDN can provide. ...."
> Are there plans to provide fine granularity?
>
I don't understand the question.
> - Nalin
>
> > -----Original Message-----
> > From: Lisa Amini [mailto:aminil@us.ibm.com]
> > Sent: Friday, February 02, 2001 2:15 PM
> > To: cdn@ops.ietf.org
> > Subject: Distribution Draft
> >
> >
> > I've attached the latest draft for CDI Distribution
> > Requirements. It is
> > still very much a work-in-progress, so I would appreciate any
> > comments or
> > suggestions.
> >
> > --Lisa
> >
> > (See attached file: draft-cdnp-distreqs-2.txt)
> >
>