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:aeon-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu)
Sent: Friday, May 23, 2014 6:12 PM
To: aeon@ietf.org
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, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
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
Aeon@ietf.org
https://www.ietf.org/mailman/listinfo/aeon