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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 23 May 2014 23:11:51 +0000

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
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 27 May 2014 22:22:01 +0000

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:

>has been successfully submitted by Charles Eckel and posted to the IETF 
>repository.
>
>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

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 May 2014 22:52:41 +0000

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.

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

>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
>Subject: [Aeon] FW: New Version Notification for 
>draft-conet-aeon-problem-statement-00.txt
>
>addressing review comments received to date. Please review and share 
>your comments.
>
>Cheers,
>Charles
>
>>IETF

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 28 May 2014 09:30:14 +0000

> Can you give a few examples of what those "flow characteristics" are?

This needs to be discussed further, but my initial thought on this are that we need to have simple and to the core values we can act upon. Thinks like bandwidth usage, latency requirement, packet loss tolerance would be helpful. Having a higher level of description like Audio, Video or application data might be useful, but it all boils down to the “core” flow characteristics. The characteristics must also be dynamic and expected to change during the lifetime of the stream. A video stream can be very “elastic” in its behavior dependant on how much movement there is in the picture and so on. 

> 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? 
For encrypted video streams is is possible to send unencrypted packets (For example STUN) multiplexed in the same stream. Those packets can contain information about the stream characteristics. But we need to make sure we do not leak any unwanted information, so it is important that the characteristics we describe are standardised and well understood. (I would consider the stream characteristics as “envelope” information. Like an Air-mail stamp on an envelope)

> 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…
Loss of information when crossing administrative domains is a big problem. Having the application talk to each of the controllers in the different administrative domains is also going to be complicated. How do the client discover what controllers to speak to? 

One thing we probably should mention in the problem statement draft is that it is important that we come up with a solution that is easy for the clients to implement and use. I think that is a key point if we want this to be successful. 

On approach we are playing with is described in:
http://tools.ietf.org/html/draft-martinsen-tram-discuss-00

Think of this as DSCP, ECN and a bit of RSCP signalled using STUN messages sent in-band in the flow. The edge device needs to pick up those STUN messages. Code for doing that looks roughly as:

bool stunlib_isStunMsg(const uint8_t *payload, uint16_t length)
{
    /* first 2 bits must be 00, STUN header and magic cookie */
    return (((*payload & STUN_PACKET_MASK) == STUN_PACKET)
        &&  (length >= 20)
        &&  (memcmp(payload+4, (void *)StunCookie, StunCookieSize) == 0));
}

This puts some stress on the devices that needs to detect those messages, but should be much easier than doing DPI. 

.-.
Pål-Erik