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

["Charles Eckel (eckelcu)" <[e-mail]>]

On 2/4/14 3:19 PM, "Paul E. Jones" <[e-mail]> wrote:

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

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

>
>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.

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.

>
>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.

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 :)
 
>
>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?

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.

>
>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?

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.

>
>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?

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.

>
>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.

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.
 
>
>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.

Me, too. 

>
>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.  

I actually thought it implied the former.

>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"?

Not sure. The solution section is TODO :)

>
>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.

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

>
>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
>