Hi,
It was good to see such a large turnout at the AEON discussion at IETF 89.  Here are the meeting minutes...  There was quite the lively discussion and I tried to capture most of the comments that were raised.  I will add my comments in a different e-mail to the list.

Regards,
Wu-chi

In attendance: approximately 30 people

Agenda
  *) Problem statement review - Charles Eckel
  *) Opinions from people

Charles went over the problem statement and had discussions regarding questions / comments people had.

Some of the discussion points included:

*) Some comments regarding quality of service
  The goal is to be able to benefit applications

*) Is adaptation a focus?
  Yes, it is.  Perhaps, this need to be brought up more clearly in the draft.

*) Are there other flow characteristics that are not QoS related?
  In some routing, you may want to avoid parts of the network.  An example of not routing through a particular country came up.

*) A brief discussion regarding whether the goal of AEON is to benefit te service provider or the user.
  The goal is to do both.  If you can't help both then there would be no need to use the protocol.  That is, if the user isn't benefiting, then it wouldn't use AEON.  Similarly, if the network doesn't benefit, it would ignore the messages

*) Discussion regarding the TAPS BOF occurring on Wednesday.
  There seems to be a bit of a complementary interaction between these
  TAPS: Users-> transport services
  AEON: application (transport) -> network

  It was acknowledged that this might be useful.  Having people in the room that were interested in TAPS is useful.

*) How do you do scaling, aggregating, bundling of flows
  It is up to us to define.  There was a bit of discussion regarding what it meant for an application to bundle its flows together and how the network might react to it.  Clearly, AEON will need to address such bundling.

*) Discussion regarding whether the network can trust the declaration and whether or not it is the same as diff-serv
  It depends on what is being shared and how the network is using it.  In the simple case the applications may not have a reason to lie and feedback from the network may be information (here, the app benefits from feedback and the network benefits from essentially having the app better behave / match up to the network resources).  More complicated scenarios may need authentication.  This will need to be discussed.

*) Authentication, flow control, admission control, etc seems overly complex
  There was a discussion that if we did need authentication that it would raise the complexity level significantly.  In total, it will depend upon what the action required is...  the more complex, the mor need for authentication.  A point was brought up regarding DSCPs and that they were not meant to do policy.  It was also noted that AEON is intended to do both sending and receiving policy for a user..

*) Comment regarding QoS only being needed when the network is overloaded.
  A response was that the network could use it to optimize routing decisions.  For example, splitting network traffic over wired and satellite links (or not routing through particular areas)

*) Comment regarding Skype working over everything, why bother?
  It seems a basic cost / benefit analysis might be useful.  If people developing Skype want to incorporate AEON, the app needs to benefit for the added complexity.  It might be useful to do such an analysis.


*) Comment regarding perhaps getting more application folks involved, otherwise might be an issue
  There seemed to be general consensus that this was a good idea... otherwise it might never be used.

  There was a discussion about the WebRTC WG as well as the STUN / Malice work ongoing.

*) Question regarding where is enforcement of AEON?
  Could be information or enforcement.  It could be done at any network device (e.g., AP, L2 / L3 router / switch).  Anything that sees the packet could act on the flow