2.1.17 Content Distribution Internetworking BOF (cdi)

Current Meeting Report

Content Distribution Internetworking (CDI) BOF
March 20, 2001
Notes by Sean Butler, <sbutler@akamai.com>
Minor editing by Mark Day, <markday@cisco.com>

- Successor to CDNP BOF at IETF 49, working towards WG status
- Intellectual Properties/Patent issues
- Mark Day presented briefly on the issues, and pointed people to RFC 2026
- Model document - Mark Day
- dependent on WREC
- incomplete
- redundant with other drafts
- will be the "intro to CDI" doc
- editors of other drafts need to pull out terminology and intro material and move it here
- Scenario document - Phil Rzewski
- lists types of CN's
- Internetworking scenarios
- Accounting scenarios
- interdependencies
- not much response yet
- need consensus on CN's
- prioritize scenarios so protocols attack them 1st
- need feedback!
- Content Internetworking Architecture document - Mark Green (sub for Gary Tomlinson)
- request-routing, distribution, accounting systems connect via CPG's
- major issues

- need review of current draft ASAP
- Known request-routing mechanisms - Abbie Barbir
- covers all known techniques, including DNS, transport layer and application layer
- pros and cons to each discussed
- measurements - active vs. passive
- draft needs to be moved to RFC
- Request Routing Requirements - Brad Cain
- directing clients to the best surrogates
- gather requirements for interconnecting RR systems
- interaction with DIST and ACC systems
- major issues:

- need comments, especially on MUST vs. SHOULD issues
- Distribution peering requirements for CDI - Lisa Amini
- distribution advertising, content signaling, content advertising
- Resource Update Protocol (RUP) from WEBI
- distribution advertising: advisory, not binding (i.e. you are not committing to anything)
- content signal - yes or no, not negotiating
- meta-data: is it all that is needed?
- comments needed on draft
- Accounting Peering Requirements for CDI - Phil Rzewski (sub for Jay Guha)
- define scaleable framework - leverage AAA
- Inter-CN only (not intra!)
- not much input on this document!!!
- SP and CP's need to give input
- what can be done?

CDI timeline:

May 1: new versions of requirements, incorporating discussions from the meeting
June 1: last call for requirements
August 5-10: WG meets at London IETF to (re)charter


- comments on accounting side:

- Q: leave open to add fields, etc. later, extensible to new data types

- A: Phil: we need specifics for the vendors to incorporate the protocols into their products

Mark: intended to be records to represent all events of interest no matter what value model is used

- Q: IESG slaps down anything where DNS is modified (in terms of encoding content types)

A: expect push back for images.foo.com vs. www.foo.com

- Q: when did content distribution inter-networking come about vs content peering

A: Phil: this was pushed on the mailing list due to several reasons, including content networks (CDN, access content network, etc.).

"peering" was not good because it includes connotation of settlements, etc.
(should it just be content inter-networking? should "distribution" be removed)

- Q: in draft, emphasis was on CNAME for DNS (the question is should CNAME be a MUST)

A: Brad: CNAME would be supported, but it would not be listed as the only way. But CNAME for DNS is a must in RR.

- Q: Are records that are being produced to be batch or real-time? (real time has some merit in various situations)

A: Mark: Currently being left fuzzy. Off-line only may not be acceptable, but some don't want to require it to be on-line.

This should be picked up on the mailing list.

- Q: For Lisa regarding advertisement of capacity? Is it a commitment or not?

A: Lisa: It is not a reservation, it is an advertisement of capability. If the source accepts it, then the content is injected. Then the destination makes a commitment when it receives it, that it can make the delivery as specified.

Mark: Contracts to ensure these types of things are outside the scope of the IETF. (Business aspects, like rates, guarantees, penalties, etc.)

Lisa: This is a mechanism for parties to do these kind of things -- i.e. the requirements are that there be enough information to fulfill the business requirements.

What parameters are reasonable and manageable within the protocol, yet can be used on the business model side?

- Q: Is there a discovery mechanism taking place? I.e. if I say I can do 100 streams, but the requester needs 1000, is that the end of the discussion.

A: Looking at aggregating information based on IP prefix or AS. Trying not to give away proprietary information.

Phil: auto-discovery and auction/bidding is probably too grand to pursue here

- Q: What kind of capabilities does a CN have? Types of traffic capacity, etc. What is in scope here?

A: These attributes are all in scope. See the distribution advertisement section for what can be advertised.

- Q: QOS negotiation is not a part of the WG for now. Are two willing CDNs precluded from doing such negotiations based on what the WG is going to do?

A: Brad: two components: dynamic provision which is hard, and request routing. For RR exchanging multiple metrics for routing decisions should be a part of the protocol...

Mark: the standard will hopefully not prevent the two parties from doing negotiations for QOS.

Brad: the documents leave room for extensibility when possible, though the WG may come across cases where a choice has to be made.

- Q: Has peer to peer networking been discussed in CDI

A: Mark: It came up in October at the CA meeting. In a way it is out of scope. A p2p network that says its a CN, and wants to interoperate with other CNs is in scope.

Phil: encourages a p2p expert to submit a scenario to the group.

- Q: No discussion of charter.

A: Mark: Charter has been submitted but not approved. IESG may now be looking at it and making revisions. Charter was a big piece of the last BOF.

- Q: CDNs are becoming application distribution networks, so the capabilities advertisements which are mostly static based may not be enough.

A: Mark: accepted as an architectural concern and that what we do now must be extensible.

Phil: Let's focus on the immediate need of static inter-operation, which is a need today. There is an evolution from static to streaming to whatever....


<A HREF="/slides/cdi-a/index.html">Agenda</A>