comments on various CDN Internet Drafts

[hoe@zurich.ibm.com]

Dear all,

I am interested in content peering mainly from a storage management
perspective, and have therefore read/browsed through the currently
available Internet Drafts. Here are some comments (many of them on a
syntactic level, for now) that may be of some help. (I havn't had a
chance to follow the discussions on the mailing list so far -- can
someone please point me to an archive, thanks)

Best regards,
Christian

Christian Hoertnagl
Research Staff Member
Distributed Systems and network management group
IBM Zurich Research Lab


draft-day-cdnp-model-05.txt

+ p.9 "AUTHORATIVE REQUEST-ROUTING SYSTEM": the following sentence
  from the request-routing requirements document should be added to
  the definition to make it more precise: "REQUEST-ROUTING SYSTEMs
  MUST be able to respond to request-routing requests for content for
  which they are authoritative" (on p.8).

+ p.10 "DISTRIBUTION ...": the paragraph does not make it clear
  whether communication of CONTENT SIGNALs (as opposed to CONTENT) is
  part of DISTRIBUTION as well (I guess it is)

+ p.11 "REQUEST-ROUTING": append "Some state-of-the-art
  request-routing techniques are presented in [6]."

+ p.11 "REQUEST-ROUTING SYSTEM": definitions of ACCOUNTING SYSTEM and
  DISTRIBUTION SYSTEM do not include "single CONTENT NETWORK"
  constraint; maybe it should be added for reasons of symmetry/clarity

+ p.11 "Receives a mapped request": if use of REQUEST-ROUTING is
  preferred over MAPPING, then what's the corresponding verb to use ?

+ p.11 "Because CDNs contain": perhaps clarify as "Because CDNs
  contain ... as discrete elements"; I understand that
  e.g. proxy-cache-based CNs contain (implicit and very simple)
  request-routing systems as well

+ p.13 "DISTRIBUTION PEERING": send-only (INJECTION) and receive-only
  forms of DISTRIBUTION PEERING are mentioned in this and other
  documents; maybe extend definition to clarify these sub-terms

+ p.13 "PEERING SYSTEM": it may be worthwhile/correct to add that
  peering starts with pairwise ralationships, and meshes can then be
  built by aggregating such point-to-point connections; from the
  second paragraph in section 3.1 [3] it would seem that PEERING
  SYSTEMs always constitute parts of CONTENT PEERING GATEWAYs (the
  corresponding SYSTEMs, such as DISTRIBUTION SYSTEMs, on the other
  hand belong inside the CONTENT NETWORKs); other descriptions seem to
  suggest that each CONTENT NETWORK provides its own PEERING SYSTEMs
  as external interfaces, or that PEERING SYSTEMs are an accumulation
  of corresponding elements from across all participating CONTENT
  NETWORKs (e.g. Figure 3 in [2]); please clarify definition; similar
  (small) inconsistencies exist for the exact relationship between CNs
  and CPGs

+ p.14 "Because CDNs contain": see above

draft-day-cdnp-scenarios-03.txt

+ both CN and CDN are used in this document in similar contexts; maybe
  it should settle for one or the other

+ p.2 "for developing the requirements given in [3]": shouldn't the
  other two requirements documents (besides AAA) be referenced as well ?

+ p.3 "bound to a particular caching proxy": there may be several
  caching proxies within each ACN's domain; would switch to plural

+ p.3 "A Publishing Content Network (PCN) is an ORIGIN": in [1] ORIGIN
  is described as a server (or set of a servers), it's attribution as
  CN (with AUTHORATIVE REQUEST-ROUTING SYSTEM, etc.) therefore seems
  unnatural

+ p.3 "its own surrogates": SURROGATEs in upper-case

+ p.3 "does not operate its own surrogates or REQUEST-ROUTING system"
  ...  "BCN may also choose to participate in REQUEST-ROUTING
  PEERING": this seems to contradict (peering by definition requires
  corresponding systems)

+ p.4 "ORIGIN CONTENT NETWORK": not defined in [1]; definition should
  relate to AUTHORATIVE REQUEST-ROUTING SYSTEM

+ p.5 "AUTHORATIVE DIRECTION SYSTEM": should read "AUTHORATIVE
  REQUEST-ROUTING SYSTEM"

+ p.7 "any or all of the peered CONTENT NETWORKS": "any or all of the
  DISTRIBUTING CONTENT NETWORKs" would be more precise

+ p.8 "DISTRIBUTING CDNs": use "DISTRIBUTING CNs" for better consistency

+ p.9 "enter into;": "enter into"

+ p.9 "It likely": "It is likely"

+ p.10 "4. Accounting": it would be interesting to see a discussion of
  possible fraud issues; what prevents praticipating CNs to send out
  wrong accounting information, say, in order to have revenue flow in
  their direction, although they may not have delivered corresponding
  services; what's the trust model assumed/monitored, etc. ?

+ p.11 "BILLING": "billing" (term not defined)

+ p.11 "is therefore not important to consider": "is therefore not
  important to consider at the level of interfaces between CNs"

+ p.11, at end of section 4.1.2: "An example of this concept concerns
  online advertisement."

+ p.12 "fee associated with the reception of CONTENT": according to
  section 4.1.2 (distribution has value), the fee could also be associated
  with the sending of CONTENT; maybe use "transport" or another more
  generic term (or is this scenario specifically about the value of
  content only ?); this also applies in part to the other scenarios
  presented in sections 4.2.x

draft-green-cdnp-gen-arch-03.txt

+ p.3: again there is a bit of confusion between the term CN and CDN
  throughout this document; maybe a brief clarification should be
  copied from [13]

+ p.3 "used in, this": "used in this"

+ p.3 "control selection of the delivery Content Network": unclear

+ p.3 "interconnect several": "interconnect a selection of the frist
  three" is more precise, since SURROGATEs are never directly
  interconnected under the assumptions of this model

+ p.5, Figure 1: several box corners are "|"s, not "+"s (trivial, of
  course ;-)

+ p.6 "administration .": "administration."

+ p.6 "loosely modeled after BGP": this is a rather sudden switch in
  context; until now, the subject treatment was fully abstract and
  concentrating on requirements and scenarios; now this jumps to a
  sudden conclusion as for the right technical choice; maybe BGP-ness
  should be mentioned only later on, or with qualification (e.g. state
  observation that the environment resembles what shaped BGP in the
  routing area)

+ p.6 "delegate authority": is should be clarified what this means
  exactly; I understand that a request-routing system, after having
  received such authority, is free to route request to whatever
  SURROGATEs it deems appropriate, and not necessarily e.g. to the
  host whose (symbolic) IP address appears verbatim in the URI

+ p.6 "common convention for encoding CN metadata into the URI name
  space": where is this further explained? (perhaps add reference to
  section; there is a little bit of further information in bullet item
  2 in section 3.3, bullet 5 in section 3.6)

+ p.7: the first paragraph of section 2.1 lists the systems (not
  PEERING SYSTEMs) as core elements; I'm still a bit confused by the
  mix of those two sets of (distinct?) terms (see above); the same
  paragraph mentions SURROGATEs as core elements as well (asterisk
  missing)

+ p.7 "CONTENT which is pre-populated (pushed)": is there an
  intermediate version/scenario as well, where content is first pushed
  into CNs, and later on pulled in by clients (or pre-fetched towards
  them)? this may be more realistic that a pure pull-based scenario
  across multiple CNs; in fact section 4.2 in [2] mentions something
  of this sort

+ p.8 "feedback ADVERTISEMENTs" (multiple occurences): either CONTENT
  SIGNALs (bullet item 3) or REQUEST-ROUTING ADVERTISEMENT (bullet
  item 5) seems to be the right term here

+ p.8 "due to URI name space delegation, the request is actually made
  to the REQUEST-ROUTING PEERING SYSTEM": I would put this
  differently: the request will always be made to the REQUEST-ROUTING
  (PEERING) SYSTEM, because this is a static property of the CDI
  model/architecture; however, URI name space delegation may lead to
  the request being actually handled/satisfied by an arbitrary
  SURROGATE server

+ p.8 "Access Control Network": add reference to [14] (scenarios
  document)

+ p.10 "is responsible for routing CLIENT requests to an appropriate
  peered CN": perhaps refine to "to a SURROGATE in an appropriate
  peered CN; the selection of a particular SURROGATE is left as a
  local task to the selected CN, and is outside the scope of the
  REQUEST-ROUTING PEERING SYSTEM at large" (this is e.g. in line with
  the last paragraph in section 3.2, but then bullet item 1 in section
  3.3 suggests that the request-routing should lead all the way to
  the selection of a single SURROGATE -- needs more clarification)

+ p.10 "the only requirement of the request-routing system": use
  upper-case for REQUEST-ROUTING SYSTEM

+ p.10 "in path caching proxy": "in-path caching proxy"

+ p.11 "more than one request routing tree": use plural for "trees"

+ p.11 "REQUEST-ROUTING CPG": this should be replaced, or the term
  should be defined in relation to REQUEST-ROUTING (PEERING) SYSTEM
  and CPG (multiple occurences; holds for ACCOUTING CPG, DISTRIBUTION
  CPG as well)

+ p.13 "to the syntactical grammar defined in [7]": is this reference
  to the Real Time Streaming Protocol correct ? I would rather expect
  a document on URI formats here

+ p.13 "use a compatible request-routing mechanism": first mentioning
  of this term; perhaps add reference to [16] (known mechanisms)

+ p.14 "content-aware request-routing systems": undefined term;
  perhaps align with terminology presented in [16] (application-level
  request-routing)

+ p.14 "the merits of designing a generalized content routing
  protocol, rather than relying on request-routing mechanisms: "the
  merits of a generalized protocol for REQUEST-ROUTING PEERING, rather
  than relying on existing request-routing mechanism"; content routing
  and request-routing are not complementary terms as such

+ p.14 "DISTRIBUTION ADVERTISEMENT SYSTEM": undefined term; use
  "DISTRIBUTION SYSTEM and its ADVERTISEMENTs" instead

+ p.15 "must to consider the distribution policies involved in Section
  4": reformulate

+ p.16 "moving content closer to the CLIENT": "one goal of the Content
  Internetworking system is to move content to the CLIENT and to
  potentially optimize by moving such content closer to CLIENTs
  ahead of their requests"

+ Figure 4: other Figures show (DISTRIBUTION) CPGs outside the ranges
  (rectangles) of peered CNs; this one does not (but then the last
  paragraph of section 1.2 in [17] also suggests that CPGs are parts
  of CNs; that's a bit confusing)

+ p.18, last paragraph in section 4.1: it may be helpful to indicate
  why the distinction between INTER-CN distribution peering and
  INJECTION peering is made, and whether there is a functional
  difference (e.g. different protocol aspects), in particular

+ p.18 "add a exchange network": the rest of the sentence does not
  make fully clear what is meant by content provider network (a term
  left undefined so far), and which CN is addressed (I guess it's CNs
  A and B), if "the example above" refers to Figure 4 at all

+ p.18, last paragraph in section 4.2: this suggests that the
  difference between CONTINOUS MEDIA and other CONTENT is mainly about
  caching inside SURROGATEs; the original definition refers to
  additional timing requirements instead

+ p.19 "Replication involves moving the content from an ORIGIN server
  to SURROGATE servers": does replication only refer to the whole
  end-to-end process, or can adjecent CNs not replicate content
  locally, without the ORIGIN necessarily having to participate at
  this stage at all?

+ p.19 "such information such as": error

+ p.19 "Replication systems": undefined term; use DISTRIBUTION SYSTEMs
  instead

+ p.20 "a well-known state machine": why is this a specific
  requirement under advertising?; I would rather (implicitly) subsume
  it under requirements for a protocol (whose implementation may then
  give rise to proper state machines, etc.)

+ p.20 "use of TCP or SCTP": TCP is not normally contrasted against
  soft-state protocols; maybe add examples of the latter to clarify
  the point

+ p.22 "how do replication systems forward a request?": here a
  reference to a CONTENT REQUEST (as opposed to REQUEST-ROUTING
  REQUEST), and hence a distinction between the two (sub-)terms as
  proposed elsewhere, would make good sense

+ p.22 "How are policies communicated": without anticipating on-going
  policy work, it would be helpful to add some coarse examples showing
  the possible role of concrete policies in relation to content
  peering; ; bullet item 4 in section 2.1.2.1 of [17] gives a hint;
  could policies e.g. also be used to cause certain replications to be
  carried out when overall net traffic is low, say?

+ p.23 "CPG exchanges": are these places for enquiring about other
  CPGs available for peering ? explain

+ p.24 "using SNMP or FTP": this sounds like an odd pair/match;
  therefore I would extend to "using SNMP or FTP (appropriate for log
  files)"

+ p.23 "in an asynchronous manner (push)": "(push)" or "(pull)" ?

+ p.25, Figure 5: how do you make sure there is only one BILLING
  ORGANIZATION per CONTENT item; in the similar case of ORIGINs (and
  AUTHORATIVE REQUEST-ROUTING SYSTEMs) this is achieved by arranging
  REQUEST-ROUTING SYSTEMs in a tree topology; what's the mechanism
  applied here (e.g. to prevent that multiple billing organizations
  charge for a single transaction, say); a tree will not do because
  (as is shown in Figure 5) there may be more than one "root node",
  namely both the ORIGIN and BILLING ORGANIZATIONs, who both require
  receiving ACCOUNTING ADVERTISEMENTs

+ p.27, "Network elements within the Content Internetworking system
  are considered to be "insiders" and therefore trusted": is this a
  realistic assumption, given that different CNs may belong to
  different administrative domains?; after all, there is a reason that
  CNs give away only part of their information (via the
  protocols/interfaces defined by CDI), and keep the rest private; a
  realistic system should perhaps allow peering CNs to both cooperate
  and compete (depending on the type of content, strategic issues,
  etc.); it should include mechanisms (either strict or via
  incentives) to prevent them from frauding each other, etc. The rest
  of section 6 seems to take this partly into account, but then this
  overall statement seems misleading (and should only refer to
  "network elements within a single CN").

+ p.29 "Denial of service attacks": they can also (an in the
  conventional case also foremost) be targeted at the CNs SURROGATEs

draft-cain-cdnp-known-request-routing-01.txt

+ add the usual reference to framing documents, such as the one on
  model/terminology

+ maybe (consistently) exchange use of CDN by CN (as in other
  documents as well)

+ p.2: "can be thought off": error

+ section 2: add references to proper documents/RFCs covering DNS

+ section 2.8: a further argument against could also critizise its
  abuse of Internet transparency (similar to arguments from NAT
  debate); the same would apply to transport-layer request-routing as
  well

+ section 4: "can provide better control over the selection of the
  best surrogate, due to their exposure to the client's IP address":
  this is not specific to the method, in fact it better fits in as a
  relative advantage of the transport-layer-based technique

  I my view, the main advantage of application-layer based
  request-routing (URL-based, in particular) is that it takes all
  components of each URI identifying items of CONTENT into account,
  and hence can provide the best granularity for load balancing,
  etc. (and hence also the best scalability)

  it (and other application-based methods) is also the best solution
  in terms of sustaining transparency at lower protocol layers

  third, here it's most straightforward to take application-specific
  context information into account; e.g. shopping transactions from an
  e-commerce site can usually be distinguished from more idle browsing
  simply by checking the URIs involved, and clients/customers who are
  about to order/pay may be given better content delivery treatment by
  using application-based techniques

+ p.9 "by using a software tools": error

+ section 4.2.3, bullet 1: this is seen as an advantage/requirement by
  some, because it allows the origin to maintain accurate hit count
  count information (for advertising purposes, etc.); however, with an
  elaborate ACCOUTING PEERING SYSTEM, this information could be
  gathered via more elegant means

+ p.12 "Passive measurements": perhaps refer to them as in-bound
  measurements as well

+ p.12 "Metric Types": as the CDI infrastructure developes, cost-based
  metrics should increasingly play an important role as well; various
  QoS-related metrics (e.g. DiffServ PHBs) come to mind as well

+ p.13 "Well-known Metrics": fault-tolerance-related, and
  price-related metrics (e.g. UPS available) may play a role as well
  (see above)

draft-cain-request-routing-req-01.txt

+ the terms content type (e.g. static, streaming), and request-routing
  type (e.g. DNS-based, in-line) play an important role; their
  definitions should be given early on (perhaps use upper-case letters
  for these, as well as area and content advertisements, as in
  [MODEL])

+ maybe (consistently) exchange use of CDN by CN (as in other
  documents as well)

+ p.1 "in order too enable": error

+ section 1.2: change heading to "Overwiew of Request-Routing System
  for Content Peering", otherwise one expects a recapitulation of what's
  in [KNOWN_MECH]

+ p.1 "surrogates are part of the distribution system": this is in
  conflict with other statements, which say that both SURROGATEs and
  the DISTRIBUTION SYSTEM are elements of CNs next to each other

+ p.2 "Content Topology Database": maybe add "This is the functional
  equivalent of routing tables in conventional forwarding schemes for
  IP packets (not content)."

+ p.2 "capabilities, content advertisements, and network advertisements":
  [MODEL] mentions REQUEST-ROUTING ADVERTISEMENTs only

+ section 2.1: this should best be replaced by a reference to
  [KNOWN_MECH], not least in order to align differences in terminology
  (e.g. in-line vs. application-layer, transport-layer seems missing
  here); some of the arguments mentioned here should be worked into
  the other document, where they may be currently missing:
  e.g. DNS-based methods cannot reveal clients' IP addresses to
  REQUEST-ROUTING SYSTEMs

+ p.4 "a Layer-7 router or Proxy situated close to a client": although
  this will be the common case, it's not necessary for such a router
  to reside close to clients; in fact solutions exist that route
  requests inside server farms, based on such decisions (e.g. IBM, HP);
  I would therefore leave the geographic qualification out

+ p.5 "router R..": remove one dot

+ p.5 "cilent": error

+ p.5 "Request-routing systems present a "black-box" view of their
  associated distribution systems": unclear; the very nature of the
  REQUEST-ROUTING SYSTEM itself is maintained as a black-box by the
  present architecture, which is only specifying interfaces for its
  building blocks; DISTRIBUTION SYSTEMs have their own interfaces (for
  DISTRIBUTION PEERING SYSTEM)

+ p.5 "posseses": error

+ p.5 "is only aware of its direct neighbor": singular or plural ?;
  see previous comment about basic point-to-point nature of peering

+ p.5 "Request-routing systems are associated with one or more
  distribution systems": unclear; I understand that each
  REQUEST-ROUTING SYSTEM is associated with either no or one
  DISTRIBUTION SYSTEM insofar as each CN contains up to one system of
  each kind; if association refers to a wider scope than a single CN,
  the relation should be more precisely defined

+ p.6 "maybe": "may be"

+ p.8 "SHOULD treat other networks as "black boxes"" (and accompanying
  note): what's the reason for considering SHOULD instead of MUST at
  all? does this relate to optional, vendor-specific extensions (which
  may still be ignored) ?

+ p.8 "at least one common type of request-routing": this seems to be
  obsolated by a more specific requirement relating to CNAME-based
  DNS-based REQUEST-ROUTING given below

+ p.8 "MUST communicate their request-routing type to neighbors":
  plural (types), e.g. because of next requirement ("MAY be able to
  utilize more than one")

+ p.8 "Common formats for content identification SHOULD exist such
  that DNS redirection may occur based on the content type": I think
  this requirement should remain at level SHOULD (not MUST); refers
  also to but-but-next requirement

+ p.10 "Z static http": how can this be understood as a metric?

+ p.10 "CONTENT UNIT advertisement": elsewhere called "CONTENT
  ADVERTISEMENT" (multiple occurences)

+ p.11 "This graph information MUST be used to prevent request-routing
  loops": It should be left in the CDNs' local responsibilities to
  decide how they want to accomplish loop prevention

+ p.12 "should support neighbor discovery": relevant work is going on
  in other IETF working-groups, and perhaps should be taken into
  account/on board here (service discovery, etc.)

+ p.12 "protocols for MUST": error

+ p.12 "provide properly identify": error

+ p.13 "the online list of claimed rights": where is this kept?;
  add explicit URL

draft-amini-cdi-distribution-reqs-00.txt

+ p.1 "larger scale, or reach": [8] describes these as different
  quanities (this use suggests they are synonym instead)

+ p.1 "from one Distribution CDN to another Distribution CDN": perhaps
  rephrase as "from the DISTRIBUTION-SYSTEM of one CDN to another
  ones" (or define new term); notice that DISTRIBUTING CN is already
  taken

+ p.3 "who communicates": which

+ p.4 "full peering": possible alternatives terms for full peering:
  all-component peering, maximum-peering, triple peering; for
  component peering: some-component peering, selective peering

+ p.4 "all information that flows between the various CDI components":
  I think of communication inside CDNs (black boxes) as comprising
  vertical and horizontal portions (in comparison to Figure 2);
  neither is the subject matter of CDI; an example for vertical
  communication is e.g. between a DISTRIBUTION SYSTEM and
  REQUEST-ROUTING SYSTEM that are both local inside a single CDN, as
  stated; an example for horizontal communication is e.g. between
  network elements in a single CDN's REQUEST-ROUTING SYSTEM;
  expressing this (horizontal) restriction may be more relevant,
  because although CDI won't describe this, its final protocols may
  still well be appropriate for such horizontal communication (and may
  therefore be choosen by CDNs' implementations for convenience; you
  mention this already in section 1)

+ p.5 "an example of CDI Full Peering": why does the use of proxies
  imply full peering ? I understand use of proxies is a local and
  particular choice for the REQUEST-ROUTING SYSTEM; even if a CDN
  would have a REQUEST-ROUTING SYSTEM with proxies installed, it may
  still decide not to do any accounting (at all or by itself); hence
  there would be no ACCOUNTING SYSTEM, no accouting peering, and no
  full peering; instead of this example with proxies, it may be better
  to refer to a scenario from [9]

+ p.5 "for the purpose of for": error

+ p.8 "represent pull model": prefetching (i.e. action taken by
  SURROGATEs without triggers from cache misses) may qualify under the
  pull model as well

+ p.8 "In the case of live broadcast": data may not (or need not) be
  cached on the SURROGATEs; I think the latter is more appropriate

+ section 4.4: perhaps add "an extensible data-model for meta-data" to
  bullet item 2

+ p.11 "decision may have been preceded": may (or MUST) have been
  preceded? there's this other requirement, whereby CDNs must make
  sure that it is "likely" that content can be delivered, before they
  delegate actual delivery to a peered CDN, so MUST (waiting for and
  evaluating previous advertisements) seems to make better sense (or
  is the necessary handshake/negotiation only envisaged as part of the
  replication step?); on the other hand, MAY seems justified in light
  of possible off-line negotiations (mentioned below); clarification
  in text would help

+ p.15 "as well alternative": as well as

+ p.16 "Content ID": normally, an URI serves as Content ID; is this
  new concept introduced because it identifies aggregates (Content Set
  ID), or is the idea that its lifetime may even exceed URIs' (I guess
  the former is true); maybe explicitly refer to content sets (not
  CONTENT)

draft-gilletti-cdnp-aaa-reqs-00.txt

+ p.2 "clients interacting with origin servers": perhaps refine to
  "clients interacting directly with origin servers"

+ p.7 "request "pricing" information to a CDN": request from (or
  provide to) ?

+ p.9 "layer 5 network": layer 7 ?

+ section 5.2: the handling of privacy issues in terms of forwarding
  accounting information between countries seems like a good example
  for the potential use of policies inside/together with the CDI
  architecture; compliance with ongoing IETF policy work has been
  emphasized several times in the various documents

+ "build off of": build on

+ "a model that supports either direct aggregation to home provider
  3rd party brokering": clarify/elaborate

+ important areas are not yet covered in this early version of the
  document (as is also expressed in section 8); I would like to see a
  (progressively) better alignment between proposed
  mechanisms/requirements and the accounting scenarios in [5]:
  cable/telco/ticket/calling