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

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 04 Feb 2014 23:19:23 +0000

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)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
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, "[email-masked]" 
><[email-masked]>
>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/aeon

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 14 Feb 2014 20:31:58 +0000

>comments related to the use cases draft.

No worries, especially since we took equally long to respond.

>contributions forwarded to Bob.

Yes, and I expect both feedback to Alice and information forwarded to Bob
to be useful in various use cases. Exactly how we achieve that is tbd and
will have its challenges.

>more important than latency that exists in video.

I agree with your point. Rather than generalize the use case, I would
prefer to break it into multiple use cases. This use cases was identified
specifically at the barBOF at last IETF. It was meant to address a home
user's need to prioritize video conferencing traffic on their home
network. Now it could be that a solution that address video conference can
address a bunch of other applications as well, but that is tbd. I changed
to title to reflect that this is a home network use cases. No additional
details have been provided yet. Volunteers are welcome :)
 
>umbrella that includes PCP?

It certainly does not exclude the use of PCP, nor does it exclude use
cases that are end-to-edge rather than end-to-end. Both are possible.

>balancing is considered here?

Not sure. Tiru posted a question to try to clarify this as well. If not
one is going to volunteer more details, we can remove it. But I will leave
it as a placeholder for now.

>pushed into the scavenger class?

My understanding of this use is that low priority traffic that can be
scheduled to run at off-peak times would be identified (e.g uploading log
files or download an upgrade overnight rather than during prime time. The
user could be compensated for this, such as not having the associated
traffic count against their data plan. But here as well, I expect others
to provide more info on the use cases. I am acting more as the editor.

>adaptation and other elastic flows in this bucket.

Whereas the first use case was real-time video conferencing, this is
streaming video. I would expect to different solution here based on the
type and nature of the traffic and corresponding requirements on the
network. At this point, I think being more specific in terms of use case
is valuable.
 
>the possibilities AEON might enable in this area.

Me, too. 

>only he latter.  

I actually thought it implied the former.

>Would this be for checking the amount of bandwidth,

Not sure. The solution section is TODO :)

>application, as well as each use case.

Very good point. The information that needs to be exchanged and how it is
exchanged can vary from one use case to the next. It may be worthwhile, at
least initially, to address security and privacy considerations for each
use cases. Here as well, contributions are welcome.

Cheers,
Charles