Re: [Aeon] FW: New Version Notification for draft-eckel-aeon-use-cases-00.txt

["Paul E. Jones" <[e-mail]>]

Charles, Tiru,

Sorry for taking so long to provide feedback.  I do have questions and 
comments related to the use cases draft.

The abstract describes AEON as having two purposes: to allow an 
application to signal flow characteristics to the network and for the 
network to provide feedback to the applications.  I can imagine a few 
ways in which flow information might be transmitted along the path, but 
feedback from the network can be a bit more challenging.  Is the idea to 
have end-to-end feedback with nodes aggregating feedback to the 
application, or would the application potentially receive feedback from 
every router or switch along the path?  I assume it's the former, but 
not exactly what I expected.  The text says "the [flow descriptions 
contributed to by a network node] may be communicated as feedback".  
This confuses me a little.  If Alice sends a flow to Bob, 
"contributions" by a network node would be received by Bob, correct?  
Does AEON intend to define how that feedback gets back to Alice?  I 
would expect feedback to be information going back to Alice, not 
contributions forwarded to Bob.

Regarding each of the use cases:

Traffic Prioritization: Videoconferencing is called out explicitly.  I 
assume it's not intended to be focused exclusively on videoconferencing. 
  For example, I might want a virtual desktop protocol to receive high 
priority, as it's an interactive interface where responsiveness is even 
more important than latency that exists in video.

Firewall Traversal: The solution for this proposed in 2.2 is to use PCP. 
  I see authorization of flows handled that way, but my interpretation of 
AEON was more of an end-to-end kind of flow description.  Perhaps that's 
wrong.  I would have expected PCP to handle authorization, but not be an 
element of AEON.  AEON would have more to do with prioritization of 
flows, assisting with ALG logic, or something else.  So, is AEON an 
umbrella that includes PCP?

Load Balancing: I don't fully understand this one.  This is just a flow 
of packets.  Does this refer to balancing the load across alternate 
paths to better utilize bandwidth down two or more separate paths, or is 
this for balancing traffic in specialized devices like ALGs, firewalls, 
SBCs, etc.?  The ALG and SBC would be maintaining some state information 
and, to some extent, the firewall may, too.  So what kind of load 
balancing is considered here?

Scavenger Class: Isn't this more-or-less the same as Traffic 
Prioritization?  In this case, it's just pushing the traffic to a lower 
than best-effort class.  It seems a little odd to suggest that AEON will 
push the traffic to off-peak hours.  Do you expect applications (e.g., 
bulk email servers) to get permission before sending, denying permission 
until a certain hour of the day?  If so, is that expected to be 
negotiated end-to-end somehow?  Or is this requirement meaning to say 
that low priority traffic flows received during peak hours might be 
pushed into the scavenger class?

Video Adaptation: Like the Traffic Prioritization example, I think this 
could be generically applied to any kind of elastic flow.  Given the 
special properties of video, this is probably useful as a stand-alone 
use case.  However, there may still be a desire, for example, to request 
an FTP transfer to reduce its bit-rate, too.  So, I think there might be 
a generic use case of "Flow Rate Management".  The section that covers 
this in detail (2.5) is focused exclusively on HTTP adaptive streaming.  
Video adaptation is a topic that, even ignoring other kinds of elastic 
flows, is broader than than that.  I think we should include video rate 
adaptation and other elastic flows in this bucket.

Mobile Hotspot / App Metadata: This makes sense, too.  It's not clear 
how this will get funneled to a management system, yet, but I appreciate 
the possibilities AEON might enable in this area.

Multi-interface selection: I assume this might be for both devices like 
phones that have a 4G and Wi-Fi data interface, as well as servers that 
have multiple NICs and network connections; section 2.7.1 seems to imply 
only he latter.  Would this be for checking the amount of bandwidth, 
end-to-end delay, or a combination of things?  Would this also perhaps 
be used to convey information such as "this network path will be down 
for maintenance at 22:00 UTC"?

There is a list of information to be conveyed for each use case.  I 
believe that security and privacy considerations is probably important 
for each one of these.  As I was thinking through the use cases above, I 
can see how security considerations might vary even from application to 
application, as well as each use case.

Paul

------ Original Message ------
From: "Charles Eckel (eckelcu)" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Sent: 1/8/2014 3:28:40 PM
Subject: [Aeon] FW: New Version Notification for 
draft-eckel-aeon-use-cases-00.txt

>On 1/8/14 10:33 AM, "[e-mail]" 
><[e-mail]>
>wrote:
>
>>
>>A new version of I-D, draft-eckel-aeon-use-cases-00.txt
>>has been successfully submitted by Charles Eckel and posted to the
>>IETF repository.
>>
>>Name: draft-eckel-aeon-use-cases
>>Revision: 00
>>Title: Application Enabled Open Networking Use Cases
>>Document date: 2014-01-08
>>Group: Individual Submission
>>Pages: 11
>>URL:
>>http://www.ietf.org/internet-drafts/draft-eckel-aeon-use-cases-00.txt
>>Status:
>>https://datatracker.ietf.org/doc/draft-eckel-aeon-use-cases/
>>Htmlized: http://tools.ietf.org/html/draft-eckel-aeon-use-cases-00
>>
>>
>>Abstract:
>>    This document describes application enabled open networking use
>>    cases. Application enabled open networking (AEON) is a framework in
>>    which applications explicitly signal their flow characteristics to
>>    the network. This provides network nodes with visibility of the
>>    application flow characteristics, which enables them to apply the
>>    correct flow treatment and provide feedback to applications.
>>
>>
>>
>>
>>
>>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aeon