Subject: [CDNi] Notes from June 7 Extended Design Team Meeting on "Adaptive Streaming"

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 8 Jun 2012 13:56:05 +0200

Folks,

Here are draft notes from the June 7 extended design team meeting. Let us know if you have comments.
Note the decision to run the next Extended Design Team meeting on HAS on Thursday 28 June (to discus the new rev of dni-has that will be published by then).

Francois 

=========================================================================

Extended Design Team Meeting of CDNI on "Adaptive Streaming"
Date: Thursday, June 7, 2012
Start Time: 07:00 PDT (e.g San Francisco, USA) = 10:00 EDT (e.g Boston, USA) = 16:00 CET (e.g Paris, France) = 22:00 CST (e.g. Beijing, China)
Finish Time: 10:30 PDT (e.g San Francisco, USA) = 13:30 EDT (e.g Boston, USA) = 19:30 CET (e.g Paris, France) = 01:30 CST (e.g. Beijing, China)

The webex recording for the meeting (missing the first 5-10 minutes of the discussion) is available at:
https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=61303992&rKey=2a6dac55fc56fbc7 

SInce the full details of the discussion is accessible through the webex recording, the notes below focus on the Action Items and conclusions of the discussions.
(by merge of notes from Ray and Francois):

intro on Extended Design Team Meeting: Francois
=====================================
* This meeting is not a formal Interim Meeting of WG, it is an extended design team meeting.

Logging and HAS: Francois
====================
See slides at: http://www.ietf.org/proceedings/interim/2012/05/29/cdni/slides/slides-interim-2012-cdni-1-0.pdf

Option 4.1:
- Larry:  He suggests that Option 4.1 could actually be used by dCDN to report "summarized" log info without making any HAS specific changes in the CDNI Logging interface. 
- Francois: I don't think that is a good idea. Lack of transparency, confusing. Eg which URI do you include in the Log record?
- Kevin: The uCDN probably needs to know what it is getting from the dCDN regarding logging. Doing log aggregation in the dCDN without informing uCDN is not acceptable
- Oskar: "Do-Nothing" name is confusing
- Francois: clarified that "Do-Nothing" means "Do-Nothing-specific-for-HAS", but it is still assumed that transport of logs on CDNI Logging interafce is standardised.

* AP: Francois to include a discussion on whether option 4.1 could be used to also include summarized log info or not.

- Francois: Is there anybody who has practical experience with per-chunk logging and feels the 'Do Nothing'-approach has a real scaling problem?
- Ben: In my experience, existing CDNs already have to deal with the high volume of per-chunk logs today so they are just making it, and the CSPs are expecting to have access to per-chunk logs. So CDNI should just assume the same.
- Larry: I think CDNs have a scaling problems and as a result will do aggregation in their dCDN anyways, so we have to deal with aggregated Logs.
- Larry: one important question is how prescriptive can we be on how aggregation/summarization is performed ?
- Francois: I think CDNI can be prescriptive and if a dCDN supporst a different summarization it will have to convert. But we need a standard format if we want interoperablity.

*AP Francois: add discussion on Larry's point about how "prescriptive" can CDNI be

Option 4.2:
- Oskar: Content Collection ID might be useful for other aspects of dealing with HAS as well (i.e. purge, acquisition, etc.)
- Francois: Agreed. But we have to think about whether one identifier for all aspects or multiple identifiers (one for each aspect) makes more sense. 

Option 4.3: 
- Francois: Important to note that there is a continuum in terms of trade-offs between level of summarization and amount of information loss. If this option is chosen, we may have to define a number of summarization approaches from which the uCDN/dCDN can choose. One of these options then should be no information loss (and thus no summarization). 
- Kevin: Support for particular logging/summarization approaches can be part of a capability exchange

*AP Francois: Add discussion on capability exchange regarding logging to next version of draft. 

Option 4.4:
- Kent: Proposes 'compressed logs'-approach, where the log files are compressed at the moment of recording the log (i.e. when two URIs are similiar, they might be stored more efficiently). This allows advantages of compression to be used during all steps of the logging process.
- Oskar: Log compression is not HAS-specific, but could be used for log files of any content (i.e. for two unrelated content items from the same uCDN)

*AP Francois: Add additional option proposed by Kent to next version of draft
*AP Francois: Add point made by Oskar regarding general applicability of log compression to non-HAS
*AP: Ben to describe proposed compression approach

Option 4.5:
- Larry: Problem with this option is that a dCDN does not just have to be HAS-aware, it has to be HAS-aware in exactly the way defined by the CDNI standards
- Kevin: What happens when some chunks come from one surrogate, and some other chunks come from another surrogate?
- Francois: yes, there are a few challenges that woudl have to be thought through with summarized logs in the presence of load-balancing. It might not be such a big issue with 'event-based logging' in case of change of surrogate mid-session
- Kevin: per-chunk load balancing might result in creating more (or at leats as many) logs as per-chunk logs.
- Ray: If we mandate a dCDN to support 'detailed pull', then what is the advantage of doing all these types of log summarization stuff anyway?
- Francois: it allows to use summarized logs on the bulk of the deliveries and still have access to detailed logs for teh specific subset of deliveries that require the full details (eg for debugging)
- Kevin: Propose to allow CDNs to dynamically communicate regarding their log capabilities/requests

*AP: Francois to add discussion on challenges of summarized logs in case of load-balancing
* AP: Francois to add discussion on supporting both a summarized Push and a detailed customizable Pull, and discussion on how to deal with different capabilities.

Recommendation:
- Option 4.1 is a MUST
- If included in CDNI, an additional option with summarization would be OPTIONAL

URI SIgning for HAS content (prezo + discussion): Kent
========================================
Kent presents introduction to URL signing . No slides available, use cdni-has

Option 5.1:
*AP Kent: Add table listing possible combinations regarding the URL signing scenarios to next version of draft
*AP Ray/Kent: Add necessary Terminology about different types/levels of manifests such as "top-level-manifest" (i.e. a manifest might only describe the different representation levels that are available and point to other manifest files for describing the chunks that make up a particular representation level)
* AP: Kent: expand the pros & cons discussion to cover the specifics of each scenario/combination (eg DNS/HTTP, types of URLs, symmetric/assymetric keys,..)
*AP Kent: Clarify effect on CDNI Interfaces for Option 5.1 (or actually the"lack of effect")

- Kevin: I don't think signing the URL of just the top-level manifest provides any security for HAS content

Option 5.3:
*AP: Kent to remove separate section for option 5.3 and just mention it as a special falvor of section 5.2

*AP: Kent : to reflect several concerns raised by Kevin and discussed (Kent noted them down as we spoke e.g. state that 5.2 provides level of security afforded by HTTP Cookies).

Recommendation:
*AP Kent: add a recommendation section stating recommendation to focus on Option 5.1

Next steps:
========
	* Ray & co-authors to rev up cdni-has: target date of 21 June
	* run another virtual meeting of extended design team for HAS : Thusrday 28 June.

---

From: David Harrington <[email-masked]>
Date: Fri, 08 Jun 2012 11:17:59 -0400

Hi,

I recommend your Intro discuss the purpose of the design team meeting,
rather than focusing on whether it is an official Interim.
i.e., What is the goal of the design team meeting?

Expand HAS on first use ...

The WG seems to be getting awfully wish-listy to me.

I get concerned when I see a WG start to add features on features ...
Unnecessary complexity can seriously hamper a standard in the field.
How many of these features MUST be implemented to meet operational
requirements (e.g., legal requirements)?
How many are nice-to-haves? (uCDN/dCDN standardized logging, log
aggregation, multiple summarization approaches, log compression, multiple
IDs, multiple URL signing scenarios, multiple levels of manifests, ...)
If you mandate all these nice-to-have-but-not-critical features,
implementers will ignore the standard.
If you add these nice-to-have but make them optional, implementers won't
implement them (to reduce costs), and you'll lose interoperability.
Focus on standardizing the core functionality that is actually NEEDED.

<soapbox> 
It is not a surprise when a group of protocol designers get together and
recommend designing a protocol ;-)
Are you starting to invent a whole new logging protocol for CDNI when
widely-used logging standards (syslog, ipfix, etc.) already exist?

The SNMP community were convinced they needed their own SNMP-specific
security.
Operators balked at having to maintain an extra security system just for
SNMP.
They didn't want to pay operators to attend classes to learn another new
security system, and have to make multiple systems work together, etc.

Existing tools already know how to gather, correlate, aggregate, forward,
and filter the existing standard logging formats.
Think of the CDNI logging customers -- the operators, regulators, law
enforcement people.
Are you going to make operators/regulators/law enforcement learn a whole
new logging protocol, and buy a whole new set of tools, just to support
CDNI?

I think the WG would be wise to look at the existing logging systems and
see how to use those to meet requirements.
What are operators using NOW for their logging requirements?
If not all requirements can be met (CDNI-specific data fields,
aggregation, compression, negotiation), maybe you should propose extended
capabilities for existing systems rather than inventing a whole new
protocol.
</soapbox>

--
David Harrington
[email-masked]

On 6/8/12 7:56 AM, "Francois Le Faucheur" <[email-masked]> wrote:

>Folks,
>
>Here are draft notes from the June 7 extended design team meeting. Let us
>know if you have comments.Note the decision to run the next Extended
>Design Team meeting on HAS on Thursday 28 June (to discus the new rev of
>dni-has that will be published by then).
>
>Francois 
>
>Start Time: 07:00 PDT (e.g San Francisco, USA) = 10:00 EDT (e.g Boston,
>USA) = 16:00 CET (e.g Paris, France) = 22:00 CST (e.g. Beijing, China)
>Finish Time: 10:30 PDT (e.g San Francisco, USA) = 13:30 EDT (e.g Boston,
>USA) = 19:30 CET (e.g Paris, France) = 01:30 CST (e.g. Beijing, China)
>
>
>SInce the full details of the discussion is accessible through the webex
>recording, the notes below focus on the Action Items and conclusions of
>the discussions.
>See slides at: 
>http://www.ietf.org/proceedings/interim/2012/05/29/cdni/slides/slides-inte
>rim-2012-cdni-1-0.pdf
>
>Option 4.1:
>- Larry:  He suggests that Option 4.1 could actually be used by dCDN to
>report "summarized" log info without making any HAS specific changes in
>the CDNI Logging interface.
>- Francois: I don't think that is a good idea. Lack of transparency,
>confusing. Eg which URI do you include in the Log record?
>- Kevin: The uCDN probably needs to know what it is getting from the dCDN
>regarding logging. Doing log aggregation in the dCDN without informing
>uCDN is not acceptable
>- Francois: clarified that "Do-Nothing" means
>"Do-Nothing-specific-for-HAS", but it is still assumed that transport of
>logs on CDNI Logging interafce is standardised.
>
>* AP: Francois to include a discussion on whether option 4.1 could be
>used to also include summarized log info or not.
>
>- Francois: Is there anybody who has practical experience with per-chunk
>logging and feels the 'Do Nothing'-approach has a real scaling problem?
>- Ben: In my experience, existing CDNs already have to deal with the high
>volume of per-chunk logs today so they are just making it, and the CSPs
>are expecting to have access to per-chunk logs. So CDNI should just
>assume the same.
>- Larry: I think CDNs have a scaling problems and as a result will do
>aggregation in their dCDN anyways, so we have to deal with aggregated
>Logs.
>- Francois: I think CDNI can be prescriptive and if a dCDN supporst a
>different summarization it will have to convert. But we need a standard
>format if we want interoperablity.
>
>- Oskar: Content Collection ID might be useful for other aspects of
>dealing with HAS as well (i.e. purge, acquisition, etc.)
>- Francois: Agreed. But we have to think about whether one identifier for
>all aspects or multiple identifiers (one for each aspect) makes more
>sense. 
>
>Option 4.3: 
>- Francois: Important to note that there is a continuum in terms of
>trade-offs between level of summarization and amount of information loss.
>If this option is chosen, we may have to define a number of summarization
>approaches from which the uCDN/dCDN can choose. One of these options then
>should be no information loss (and thus no summarization).
>- Kent: Proposes 'compressed logs'-approach, where the log files are
>compressed at the moment of recording the log (i.e. when two URIs are
>similiar, they might be stored more efficiently). This allows advantages
>of compression to be used during all steps of the logging process.
>- Oskar: Log compression is not HAS-specific, but could be used for log
>files of any content (i.e. for two unrelated content items from the same
>uCDN)
>
>- Larry: Problem with this option is that a dCDN does not just have to be
>HAS-aware, it has to be HAS-aware in exactly the way defined by the CDNI
>standards
>- Kevin: What happens when some chunks come from one surrogate, and some
>other chunks come from another surrogate?
>- Francois: yes, there are a few challenges that woudl have to be thought
>through with summarized logs in the presence of load-balancing. It might
>not be such a big issue with 'event-based logging' in case of change of
>surrogate mid-session
>- Ray: If we mandate a dCDN to support 'detailed pull', then what is the
>advantage of doing all these types of log summarization stuff anyway?
>- Francois: it allows to use summarized logs on the bulk of the
>deliveries and still have access to detailed logs for teh specific subset
>of deliveries that require the full details (eg for debugging)
>* AP: Francois to add discussion on supporting both a summarized Push and
>a detailed customizable Pull, and discussion on how to deal with
>different capabilities.
>
>Recommendation:
>- Option 4.1 is a MUST
>*AP Kent: Add table listing possible combinations regarding the URL
>signing scenarios to next version of draft
>*AP Ray/Kent: Add necessary Terminology about different types/levels of
>manifests such as "top-level-manifest" (i.e. a manifest might only
>describe the different representation levels that are available and point
>to other manifest files for describing the chunks that make up a
>particular representation level)
>* AP: Kent: expand the pros & cons discussion to cover the specifics of
>each scenario/combination (eg DNS/HTTP, types of URLs,
>symmetric/assymetric keys,..)
>*AP: Kent : to reflect several concerns raised by Kevin and discussed
>(Kent noted them down as we spoke e.g. state that 5.2 provides level of
>security afforded by HTTP Cookies).
>
>Recommendation:
>_______________________________________________
>CDNi mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cdni

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 8 Jun 2012 19:51:35 +0200

Hi David,

> i.e., What is the goal of the design team meeting?

See the agenda that was announced before: http://www.ietf.org/proceedings/interim/2012/05/29/cdni/agenda/agenda-interim-2012-cdni-1.html.

> 
> Expand HAS on first use …

These are notes intended to facilitate the work of the design team focusing on HAS. Also, this is a follow up from the first extended HAS design team meeting that happend the week before. So the target audience is very familair with HAS. We are sharing the notes with the rest of the group for transparency and to invite feedback, but we may not want to be too strict about accuracy or editorial aspects of these notes. However, volunteers for good note-taking are very welcome.

HAS is also expanded in the agenda that was announced before: http://www.ietf.org/proceedings/interim/2012/05/29/cdni/agenda/agenda-interim-2012-cdni-1.html.

> The WG seems to be getting awfully wish-listy to me.

I am not sure how much context you have here, but let me restate that there is incomplete understanding of the interactions of HTTP Adaptive Streaming with CDNI and different opinions have been expressed in terms of how CDNI should handle HTTP Adaptive Streaming (ie do nothing special, do some light-weight optimization, do a lot of optimization). Thi question has been slowing the progress of the WG (e.g. we can not close parts of the cdni-requirements, cdni-framework documents). In Paris, we identified a plan to go about that, which involves documenting these interactions and the options for dealing with them in the form of draft-brandeburg-cdni-has and use that to drive enough concensus for decisions. These design team meetinsg are mostly about accelerating this.
I'd concede that perhaps we could be a little more "aggressive" about dropping out options. But, since they come up we feel we may as well record the at the sae time, so the future decisiosn are well documented.

> I get concerned when I see a WG start to add features on features …

At this stage no feature has been added. Options are documented so that decisions can be made.
If you look at the draft recommendations discussed in the I-D or in the design team meetings, you may get a sense that the recommendations ted to err on the "go simple" side.

> Focus on standardizing the core functionality that is actually NEEDED.

As per the "Notes from May 29 Extended Design Team Meeting on "Adaptive Streaming", the Introduction to the Meeting included the following statement:
"
* Let's remember that we have a strong motivation to develop first what is REQUIRED to make HAS work. We need to focus on fundamentals to make HAS work vs how to use CDN-I to make things work better
"
So it sounds like we are in synch.

> widely-used logging standards (syslog, ipfix, etc.) already exist?

This team is not designing any protocol. It is trying to help decide how little (or how much) incremental functionality needs to be supported by the CDNI interfaces specifically for HTTP Adaptive Streaming. Most of us share your objective of leveraging what exisits (specifically for Logging).

Regarding the specific protocol candidate you mention below, the working group has not yet started working on specific detailed protocols for encoding/transport of logging information. Specific proposals levering existing protocols would be very timely. 

Thanks for sharing your concerns.

Francois