Subject: Re: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt

From: Linda Dunbar <[email-masked]>
Date: Mon, 2 Jun 2014 22:39:35 +0000

Comments inserted below:

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: Tuesday, May 27, 2014 5:53 PM
To: Linda Dunbar; Charles Eckel (eckelcu); [email-masked]
Subject: Re: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt

Linda,

I'd assume this is open for discussion, but I can imagine information such as tolerance to loss, delay, and jitter are important.

One piece of data I think would be useful to send into the network is the Traffic Class Label (TCL), which identifies with some precision what the flow is.  For example, is this a real-time gaming session, a conversational voice/video session, bulk file transfer, or other?  The TCL would tell us this.

Another piece of data might just be some kind of locally-determined priority value.

[Linda] I can see that Applications can be motivated to request those traffic characteristics from to network to achieve better services. 

Sending those traffic characteristics to network devices is so much like the User-Network interface (which was hot during 2001 time frame). After 15 years, it still didn't take off. Why:  Because there are so many access devices deployed. Service providers can't afford to upgrade such massively deployed access devices to take care of new signal, billing, etc. 

A much more realistic way is for the signal to be sent to a "broker" (or controller) that can take requests from Applications and dispatch the relevant configuration to the network elements. 

Linda 

You're correct that traffic is aggregated, but it might be useful if this information could somehow be conveyed end-to-end for the benefit of other carrier or enterprise networks.

Paul

------ Original Message ------
From: "Linda Dunbar" <[email-masked]>
To: "Charles Eckel (eckelcu)" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 5/27/2014 6:22:01 PM
Subject: Re: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt

>Charles, et al:
>
>Your Req-1 states "allow applications to explicitly signal their flow 
>characteristics to the networks".
>
>Can you give a few examples of what those "flow characteristics" are?
>
>The draft also states that DPI can't be performed when the traffic is 
>encrypted. What kind of signals will the applications that encrypt 
>their traffic send to network?
>
>
>Almost all End to End traffic are aggregated by network operators edge 
>devices (there could be many layers of operators). All the signals from 
>end devices are lost once entering provider domain. I think a more 
>realistic approach is to establish interface between applications to 
>network controllers.
>
>
>Linda
>-----Original Message-----
>From: Aeon [mailto:[email-masked]] On Behalf Of Charles Eckel
>(eckelcu)
>Sent: Friday, May 23, 2014 6:12 PM
>To: [email-masked]
>Subject: [Aeon] FW: New Version Notification for 
>draft-conet-aeon-problem-statement-00.txt
>
>The following draft is the result of merging the CoNET and AEON problem 
>statement drafts discussed previously on this list. It is intended as a 
>replacement for both of them, combining important aspects of both and 
>addressing review comments received to date. Please review and share 
>your comments.
>
>Cheers,
>Charles
>
>On 5/23/14, 4:05 PM, "[email-masked]" 
><[email-masked]>
>wrote:
>
>>
>>A new version of I-D, draft-conet-aeon-problem-statement-00.txt
>>has been successfully submitted by Charles Eckel and posted to the 
>>IETF repository.
>>
>>Name: draft-conet-aeon-problem-statement
>>Revision: 00
>>Title: Application Enabled Collaborative Networking: Problem Statement 
>>and Requirements Document date: 2014-05-21
>>Group: Individual Submission
>>Pages: 11
>>URL:
>>http://www.ietf.org/internet-drafts/draft-conet-aeon-problem-statement-00.
>>txt
>>Status:
>>https://datatracker.ietf.org/doc/draft-conet-aeon-problem-statement/
>>Htmlized:
>>http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00
>>
>>
>>Abstract:
>>    Identification and treatment of application flows are important to
>>    many application providers and network operators. They often rely 
>>on
>>    these capabilities to deploy and/or support a wide range of
>>    applications. These applications, and the packet flows they 
>>generate
>>    and consume, may have specific connectivity requirements that can 
>>be
>>    met if made known to the network. Historically, this functionality
>>    has been implemented to the extent possible using heuristics, which
>>    inspect and infer flow characteristics. Heuristics may be based on
>>    port ranges, network separation (e.g. subnets or VLANs, Deep Flow
>>    Inspection (DFI), or Deep Packet Inspection (DPI). But many
>>    application flows in current usages are dynamic, adaptive, time-
>>    bound, encrypted, peer-to-peer, asymmetric, used on multipurpose
>>    devices, and have different priorities depending on direction of
>>    flow, user preferences, and other factors. Any combination of these
>>    properties renders heuristic based techniques less effective and 
>>may
>>    result in compromises to application security or user privacy.
>>
>>
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of 
>>submission until the htmlized version and diff are available at 
>>tools.ietf.org.
>>
>>The IETF Secretariat
>>
>
>_______________________________________________
>Aeon mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/aeon
>
>_______________________________________________
>Aeon mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/aeon

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 11 Jun 2014 20:41:10 +0000

Hi Linda,

Sorry for the delated response. I was away on vacation and am still
playing catchup. Please see inline.

On 6/2/14, 3:39 PM, "Linda Dunbar" <[email-masked]> wrote:

>Subject: Re: [Aeon] New Version Notification for
>I'd assume this is open for discussion, but I can imagine information
>such as tolerance to loss, delay, and jitter are important.
>
>One piece of data I think would be useful to send into the network is the
>Traffic Class Label (TCL), which identifies with some precision what the
>flow is.  For example, is this a real-time gaming session, a
>conversational voice/video session, bulk file transfer, or other?  The
>TCL would tell us this.
>
>[Linda] I can see that Applications can be motivated to request those
>traffic characteristics from to network to achieve better services.

Great.

> 
>
>Sending those traffic characteristics to network devices is so much like
>the User-Network interface (which was hot during 2001 time frame). After
>15 years, it still didn't take off. Why:  Because there are so many
>access devices deployed. Service providers can't afford to upgrade such
>massively deployed access devices to take care of new signal, billing,
>etc.

Are you referring to NSIS? If not, can you provide a ptr? It is certainly
helpful and important to learn from the past.

> 
>
>A much more realistic way is for the signal to be sent to a "broker" (or
>controller) that can take requests from Applications and dispatch the
>relevant configuration to the network elements.

Such an approach has some nice properties. I envision there being multiple
ways to exchange well defined flow characteristics between application and
the network. Pal-Erik mentioned one way, you suggest another. A controller
based solution works very well in some scenarios, but has challenges in
others. If I understand your proposal, each application needs to discover
the right controller(s), and the controller(s) need to be able to identify
and configure the network elements in the path of each media stream
associated with the application. So there are tradeoffs.

Cheers,
Charles

> 
>
>Linda 
>
> 
>
>
>You're correct that traffic is aggregated, but it might be useful if this
>information could somehow be conveyed end-to-end for the benefit of other
>carrier or enterprise networks.
>
>Paul
>
>Subject: Re: [Aeon] New Version Notification for

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 11 Jun 2014 22:32:46 +0000

Charles, 

Replies are inserted below:

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]] 

> 
>
>Sending those traffic characteristics to network devices is so much 
>like the User-Network interface (which was hot during 2001 time frame). 
>After

Are you referring to NSIS? If not, can you provide a ptr? It is certainly helpful and important to learn from the past.

[Linda] the famous User Network Interface (UNI) which was started in 1999 (OIF started UNI project) when there was a big push on Bandwidth on Demand for video distribution, or time-based network bandwidth. After 14 years, it still hasn't been deployed very much for the reasons I stated above. 

>relevant configuration to the network elements.

Such an approach has some nice properties. I envision there being multiple ways to exchange well defined flow characteristics between application and the network. Pal-Erik mentioned one way, you suggest another. A controller based solution works very well in some scenarios, but has challenges in others. If I understand your proposal, each application needs to discover the right controller(s), and the controller(s) need to be able to identify and configure the network elements in the path of each media stream associated with the application. So there are tradeoffs.

[Linda] Applications don't have to "discover" the right controller. Wireless LTE has good model. We can borrow some concept to wireline. 

Linda  

> 
>
>Linda
>
> 
>
>
>You're correct that traffic is aggregated, but it might be useful if 
>this information could somehow be conveyed end-to-end for the benefit 
>of other carrier or enterprise networks.
>
>Paul
>
>>devices (there could be many layers of operators). All the signals 
>>from end devices are lost once entering provider domain. I think a 
>>more realistic approach is to establish interface between applications 
>>to network controllers.
>>
>>
>>Linda
>>The following draft is the result of merging the CoNET and AEON 
>>problem statement drafts discussed previously on this list. It is 
>>intended as a replacement for both of them, combining important 
>>aspects of both and addressing review comments received to date. 
>>Please review and share your comments.
>>
>>Cheers,
>>Charles
>>
>>>Title: Application Enabled Collaborative Networking: Problem 
>>>Statement and Requirements Document date: 2014-05-21
>>>http://www.ietf.org/internet-drafts/draft-conet-aeon-problem-statemen
>>>t-0
>>>0.
>>>txt
>>>Status: