Slides and notes from BOF in Minneapolis

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

The slides from last Tuesday's CDI BOF are available at
http://www.content-peering.org/2001mar20/IETF50-CDI-BOF.ppt

Notes (below) taken by Sean Butler <sbutler@akamai.com> (Thanks Sean!). 
The official minutes will be based on these notes and should come out soon.

--Mark

Content Distribution Internetworking

  IETF50 BOF

  March 20, 2001


   - 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

       - dependenton 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 Architectural Document

      - RR, DIST, ACC sub systems connect via CPG's

      - major issues

           - merging drafts from before last BOF

           - need reconcilation on RR and ACC drafts

      - need review of current draft ASAP


  - Known CDN RR mechanisms

      - 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:

            - how transparent is a CDN?  is it a black box?

            - should internal surrogates be advertised between CDNs?

            - how to support multiple types of RR systems?

                 - DNS much different from L7

            - DNS name format?

            - common format for content type?

            - how much QOS?  multi-metric? how many? what is minimal?

            - separate RR system from protocol requirements?

      - 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

     - 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?
          - should this work be moved elsewhere?
          - other proposals?  out of band, simple?
          - placeholders in RR/D until this comes back


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


Questions:

   - 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 to
              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 with the CDNI

           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....