RE: What is CONTENT?

["Maciocco, Christian" <christian.maciocco@intel.com>]

CONTENT is a "Sequence of Octects" would cover both known length content as
well as live/streaming content.
Christian

> -----Original Message-----
> From: Mark Day [mailto:markday@cisco.com]
> Sent: Tuesday, November 07, 2000 3:09 PM
> To: cdn@ops.ietf.org
> Subject: What is CONTENT?
> 
> 
> The current (-02) draft of the model document includes a 
> formulation of
> CONTENT in terms of CONTENT DATA UNITs.  No-one on the design 
> team seems to
> like this approach very much. I am happy to replace these 
> definitions or
> eliminate them entirely, but I find the leading proposed replacement
> somewhat unsatisfactory.
> 
> Barron's suggestion is that CONTENT is a "typed finite 
> sequence of octets."
> While this is correct, it seems incomplete.
> 
> I think that we need to get across the following points:
> 
> 1. We are talking about digital content -- that which can be sensibly
> carried over IP. ["Typed finite sequence of octets" does this 
> OK -- leaves
> out non-octet aligned formats, but are there any worth 
> worrying about?]
> 
> 2. There is a wide variety of digital content, and we don't want to
> inadvertently preclude using a CDN to carry some interesting 
> future format.
> Particularly, we have to avoid building file-only CDNs that preclude
> streaming delivery and live-stream delivery.  ["Typed finite 
> sequence of
> octets" is misleading here, I think.  For example, a live 
> webcam delivers a
> finite sequence of octets but its length is unknown at any 
> point before it
> ends, and it is wiser to treat it as a potentially endless 
> source of data.
> Any given network packet contains only a short sequence of octets, but
> CONTENT refers to the user-level content being moved, not 
> what's inside any
> particular message.]
> 
> 3. When resources are scarce, there is a fundamental tradeoff between
> accurate (bit-complete) delivery and timely delivery.  A CDN 
> can be asked to
> guarantee one or the other, but not both; when it is asked to 
> guarantee
> timely delivery, it must also be told what can be dropped, 
> and under what
> circumstances.  (Bit-complete accuracy doesn't require any 
> understanding of
> the format, only ensuring that all the bits are transported 
> accurately).
> [Surfacing this issue was the primary motivation for the 
> CONTENT DATA UNIT
> formulation, but it didn't do the job very well.  However, a 
> "typed finite
> sequence of octets" does worse.]
> 
> I would welcome other possible solutions to the problem I've 
> outlined. In
> the absence of other comment or proposals, I plan to use the 
> "typed finite
> sequence of octets" definition, and find a place to include 
> these issues as
> notes elswhere within the model document.
> 
> --Mark
> 
> 
>