Subject: Re: [Aeon] Charter Proposal

From: Linda Dunbar <[email-masked]>
Date: Sun, 1 Jun 2014 22:03:24 +0000

We really need to send the BOF request by Thurs (June 5) because June 6th is the BoF request deadline.

The previously proposed charter only focuses on why operators wanting to know applications. Without applications wanting to send their characteristics to network, the network has to depend on DPI (or nothing when the traffic is encrypted).

I think that we should change the angle to describe why today's applications need to send their traffic characteristics to network for differentiated services. With this in mind, I rewrote the charter proposal:

Do people on the list agree if we can send this charter  proposal to the Transport ADs (Spencer & Martin) to request a BoF in Toronto.

Linda
Description of Working Group:

Today's traffic characteristics, such as bandwidth, delay, loss, jitter, etc, are statically configured and managed by service providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure different QoS for differentiated network services, the classification is usually coarse and fixed. For example, CPE can assign different QoS to differentiate video, voice and data traffic, but CPE can't differentiate the applications under data category even though more and more data traffic are carrying video content.
It is impossible for applications to get differentiated services from public internet, such as hotspot WIFI. It is also not possible for applications to change network behavior. For example it is not easy for AntiDoS applications to enforce certain traffic to a special scrubbing center when some threat is detected.

Today, more and more applications need differentiated services from network. Some applications may need special services for a specific time span, while other applications may need to indicate their unique characteristics to the network for special treatment, especially when they send encrypted traffic.

The working group will examine what network characteristics that applications need to communicate with network, define general framework and architecture for enabling those communications, examine existing protocols for those communications, and potentially identify new protocols.
Specifically, the Working Group will:

1.  Identify the applications (or use cases) that need differentiated services, and time based services.

2. identify typical workflows for which heuristic based approaches are used
2. identify limitations of existing solutions
3. create a set of requirements for a solution based on explicit
communication between applications and the network that can be applied in
a consistent fashion across a variety of signaling protocols
4. identify a set of use cases addressable by such a solution
5. identify the information that needs to be communicated between
application and the network
6. create a framework for providing this communication between
applications and the network and that addresses the use cases
7. specify how existing signaling protocols can be enhanced to support
this framework

The Working Group is expected to work closely with other Transport area
groups.

The following topics are out of scope of this Working Group:
TBD

Deliverables:
TBD

Milestones:
TBD

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 2 Jun 2014 04:19:56 +0000

I think Peng has already sent the revised charter proposal to AD based on the updated problem statement draft http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00

-Tiru

From: Aeon [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, June 02, 2014 3:33 AM
To: [email-masked]
Subject: Re: [Aeon] Charter Proposal

Linda

Deliverables:
TBD

Milestones:
TBD

---

From: Alper Yegin <[email-masked]>
Date: Mon, 2 Jun 2014 15:00:52 +0300

Hello Linda,

> 2. identify typical workflows for which heuristic based approaches are used

It is not clear what these "heuristic based approaches" are. There is no mention of that prior to this sentence.

Alper

On Jun 2, 2014, at 1:03 AM, Linda Dunbar wrote:

> I think that we should change the angle to describe why today’s applications need to send their traffic characteristics to network for differentiated services. With this in mind, I rewrote the charter proposal:
> 
> Today’s traffic characteristics, such as bandwidth, delay, loss, jitter, etc, are statically configured and managed by service providers on per client or port basis. Even with edge devices or CPE (customer premises equipment) being able to configure different QoS for differentiated network services, the classification is usually coarse and fixed. For example, CPE can assign different QoS to differentiate video, voice and data traffic, but CPE can’t differentiate the applications under data category even though more and more data traffic are carrying video content. 
> _______________________________________________
> Aeon mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aeon

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 2 Jun 2014 22:25:58 +0000

"heuristic based approaches" as described in the problem statement is about network provider's reliance on inspection and observation, e.g. using DPI,  to detect the traffic characteristics.

Linda

From: Alper Yegin [mailto:[email-masked]]
Sent: Monday, June 02, 2014 7:01 AM
To: Linda Dunbar
Cc: [email-masked]
Subject: Re: [Aeon] Charter Proposal

Hello Linda,

Alper

Linda

Deliverables:
TBD

Milestones:
TBD

_______________________________________________
Aeon mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/aeon

---

From: "Fan, Peng" <[email-masked]>
Date: Tue, 3 Jun 2014 11:49:44 +0800

Yes Tiru I have sent the proposal request to both INT and TSV ADs last week.
Thank you Linda for your contribution, I will try to incorporate the ideas
into the draft charter.

Hi all,

The current BoF proposal can be found at
http://wiki.tools.ietf.org/bof/trac/#Internet. It includes a revised draft
charter based on the initial version before the last IETF meeting, and I
would appreciate it if you all can share opinions about the current proposal
and help revise the draft charter.

Best regards,

Peng

From: Aeon [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy
(tireddy)
Sent: Monday, June 02, 2014 12:20 PM
To: Linda Dunbar; [email-masked]
Subject: Re: [Aeon] Charter Proposal

I think Peng has already sent the revised charter proposal to AD based on
the updated problem statement draft
http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00

-Tiru

We really need to send the BOF request by Thurs (June 5) because June 6th is
the BoF request deadline. 

The previously proposed charter only focuses on why operators wanting to
know applications. Without applications wanting to send their
characteristics to network, the network has to depend on DPI (or nothing
when the traffic is encrypted). 

I think that we should change the angle to describe why today's applications
need to send their traffic characteristics to network for differentiated
services. With this in mind, I rewrote the charter proposal:

Do people on the list agree if we can send this charter  proposal to the
Transport ADs (Spencer & Martin) to request a BoF in Toronto. 

Linda 

Today's traffic characteristics, such as bandwidth, delay, loss, jitter,
etc, are statically configured and managed by service providers on per
client or port basis. Even with edge devices or CPE (customer premises
equipment) being able to configure different QoS for differentiated network
services, the classification is usually coarse and fixed. For example, CPE
can assign different QoS to differentiate video, voice and data traffic, but
CPE can't differentiate the applications under data category even though
more and more data traffic are carrying video content.  

It is impossible for applications to get differentiated services from public
internet, such as hotspot WIFI. It is also not possible for applications to
change network behavior. For example it is not easy for AntiDoS applications
to enforce certain traffic to a special scrubbing center when some threat is
detected. 

Today, more and more applications need differentiated services from network.
Some applications may need special services for a specific time span, while
other applications may need to indicate their unique characteristics to the
network for special treatment, especially when they send encrypted traffic. 

The working group will examine what network characteristics that
applications need to communicate with network, define general framework and
architecture for enabling those communications, examine existing protocols
for those communications, and potentially identify new protocols.

1.  Identify the applications (or use cases) that need differentiated
services, and time based services. 

this framework

groups.

TBD

Deliverables:

TBD

Milestones:

TBD

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 3 Jun 2014 10:51:41 +0200

Hi,
 
One question regarding the Charter Proposal.
 
Would the identification of the requirements of each application be within
the scope of the WG? I mean, is this WG going to write a document in which
different applications and services are classified, and their delay (or
jitter) requirements summarized?
 
Perhaps this is out of scope. In that case, a sentence could be added after
"The following topics are out of scope of this Working Group" stating that.
 
If this could be within the scope, here is a draft with some delay
requirements for small-packet flows:
http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#section-6> 6.
Delay recommendations . . . . . . . . . . . . . . . . . . . .
<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#page-8> 8
 
<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#section-6.1>
6.1.  VoIP  . . . . . . . . . . . . . . . . . . . . . . . . . .
<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#page-12> 12
 
<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#section-6.2>
6.2.  Online games  . . . . . . . . . . . . . . . . . . . . . .
<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#page-12> 12
 
<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#section-6.3>
6.3.  Remote desktop access . . . . . . . . . . . . . . . . . .
<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#page-13> 13
 
<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#section-6.4>
6.4.  Non real-time service . . . . . . . . . . . . . . . . . .
<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#page-13> 13
 
<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#section-6.5>
6.5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .
<http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02#page-13> 13
 
Best regards,
 
Jose
 
De: Aeon [mailto:[email-masked]] En nombre de Linda Dunbar
Enviado el: lunes, 02 de junio de 2014 0:03
Para: [email-masked]
Asunto: Re: [Aeon] Charter Proposal

 

 

Deliverables:
TBD
 
Milestones:
TBD

---

From: "Fan, Peng" <[email-masked]>
Date: Tue, 3 Jun 2014 23:09:15 +0800

Hi Jose,

Just to clarify. By "requirements" are you indicating network resources
applications are requesting for (e.g. I am a VoIP app and I request for a
100-ms-delay service from the network), or a set of criteria that the
network is supposed to meet for different types of applications (e.g. the
network is recommended to provide 100 ms delay for VoIP app). I guess we
have not considered the latter.

The former one reminds me of the information exchanged between applications
and network, though it is something in the solution scope which we have not
reviewed so much at the current problem identifying stage. From the
discussion and drafts till now, information can be something conveyed from
application to network, referred to as "characteristics", which can be
further divided into: (a) flow description that helps network identify the
traffic; (b) network resource request made by applications.

or can be something conveyed from network to application, that is (c) some
feedback made by network indicating status or whether request can be met or
not. This was also raised in Pal's message earlier.

I guess we can agree that (a) is the basic information we need to focus on.
(b) and (c) propose a good discussion point whether we will cover them as
well.

Best regards,

Peng

From: Aeon [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Tuesday, June 03, 2014 4:52 PM
To: 'Linda Dunbar'; [email-masked]
Subject: Re: [Aeon] Charter Proposal

Hi,

 

 

Best regards,

Jose

Linda 

this framework

groups.

TBD

Deliverables:

TBD

Milestones:

TBD

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 3 Jun 2014 17:27:40 +0200

Hi,
 
My idea is that "requirements" is something that an application requests
from the network (the former example): "I am a VoIP app and I request for a
100-ms-delay service from the network".
 
However, perhaps it is not necessary that the application says that. It may
only say: "I am a VoIP application". Then the network has a table with types
of services and delays, and decides to provide a maximum delay of 100 ms.
This would cover (a) and (b).
 
(c) can also be considered: if the network says to a video conference
application "at this moment I can only give you 500kbps". Then the video
conference application can adjust its codec and its video quality
accordingly. And it avoids the need for measuring the available bandwidth
continuously.
 
Jose
 
De: Fan, Peng [mailto:[email-masked]] 
Enviado el: martes, 03 de junio de 2014 17:09
Para: 'Jose Saldana'; 'Linda Dunbar'; [email-masked]
Asunto: RE: [Aeon] Charter Proposal
 
Hi Jose,

 

Best regards,
Peng

Hi,

 

 

 

Best regards,
 
Jose

 

 

 
Deliverables:
TBD
 
Milestones:
TBD

---

From: Alper Yegin <[email-masked]>
Date: Tue, 3 Jun 2014 18:50:33 +0300

Hello Peng,

What are the target deliverables for the WG-to-be-formed? 
They are not explicitly listed, but I gather "problem statement", "use cases", "gap analysis", and "requirements" from the charter text.
We better explicitly enumerate them.

Cheers,

Alper

On Jun 3, 2014, at 6:49 AM, Fan, Peng wrote:

> Yes Tiru I have sent the proposal request to both INT and TSV ADs last week. Thank you Linda for your contribution, I will try to incorporate the ideas into the draft charter.
>  
> Hi all,
>  
> The current BoF proposal can be found at http://wiki.tools.ietf.org/bof/trac/#Internet. It includes a revised draft charter based on the initial version before the last IETF meeting, and I would appreciate it if you all can share opinions about the current proposal and help revise the draft charter.
>  
> Best regards,
> Peng
>  
> From: Aeon [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
> I think Peng has already sent the revised charter proposal to AD based on the updated problem statement drafthttp://tools.ietf.org/html/draft-conet-aeon-problem-statement-00
>  
> -Tiru
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Jun 2014 15:57:00 +0000

Peng,

The current charter statement is all about applications exchanging information with network functions, such as DPI, FW, etc.

This is the Metadata,  which have been addressed by SFC WG. Why creating a new WG simply for Metadata? Besides, all traffic will be aggregated by the provider edge devices. The DPI/FW in the middle of the provider networks can't even seen those metadata attached to Applications, unless using a new header such as SFC header to carry those metadata.

Linda

From: Fan, Peng [mailto:[email-masked]]
Sent: Monday, June 02, 2014 10:50 PM
To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; [email-masked]
Subject: RE: [Aeon] Charter Proposal

Hi all,

Best regards,
Peng

From: Aeon [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Monday, June 02, 2014 12:20 PM
To: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: Re: [Aeon] Charter Proposal

-Tiru

From: Aeon [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, June 02, 2014 3:33 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Aeon] Charter Proposal

Linda

Deliverables:
TBD

Milestones:
TBD

---

From: "Fan, Peng" <[email-masked]>
Date: Wed, 4 Jun 2014 21:11:02 +0800

Hi Alper,

Thanks for the advice. I revised the proposal a little to make it clearer,
you can find the latest version at http://tools.ietf.org/bof/trac/#Internet.
We may still need to change the draft charter after further revision.

My understanding is that the short term deliverables are those background
items you gathered. Then we can re-charter to enter the solution space, e.g.
information that needs to be communicated between applications and the
network, framework for providing such communication, protocol extension to
support this framework, etc.

Best regards,

Peng

From: Aeon [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Tuesday, June 03, 2014 11:51 PM
To: Fan, Peng
Cc: [email-masked]; 'Tirumaleswar Reddy (tireddy)'; 'Linda Dunbar'
Subject: Re: [Aeon] Charter Proposal

Hello Peng,

They are not explicitly listed, but I gather "problem statement", "use
cases", "gap analysis", and "requirements" from the charter text.

Cheers,

Alper

 

Hi all,

Best regards,

Peng

I think Peng has already sent the revised charter proposal to AD based on
the updated problem statement
drafthttp://tools.ietf.org/html/draft-conet-aeon-problem-statement-00

-Tiru

Linda

this framework

groups.

TBD

Deliverables:

TBD

Milestones:

TBD

---

From: "Fan, Peng" <[email-masked]>
Date: Wed, 4 Jun 2014 21:16:19 +0800

Hi Linda,

I am trying to understand why the metadata is not visible to network. Flow
characteristics, or metadata, are conveyed to network nodes which can be a
gateway, a router, or other elements that need visibility into the traffic.
These nodes are not necessarily a DPI element, and are not necessarily
located at the edge or center of a network. Speaking of SFC metadata I would
like to know how is it related with flow characteristics we are now working
on.

We have not gone that far in discussing how the characteristics are encoded
and carried, though at the very early age of this work there were some
drafts on this. Also I remember this minutes of the barbof at London IETF
which I think is helpful in showing some of the concepts of this work
http://www.ietf.org/mail-archive/web/aeon/current/msg00025.html.

Best regards,

Peng

From: Aeon [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, June 03, 2014 11:57 PM
To: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; [email-masked]
Subject: Re: [Aeon] Charter Proposal

Peng, 

The current charter statement is all about applications exchanging
information with network functions, such as DPI, FW, etc. 

This is the Metadata,  which have been addressed by SFC WG. Why creating a
new WG simply for Metadata? Besides, all traffic will be aggregated by the
provider edge devices. The DPI/FW in the middle of the provider networks
can't even seen those metadata attached to Applications, unless using a new
header such as SFC header to carry those metadata. 

Linda

Hi all,

Best regards,

Peng

-Tiru

Linda 

this framework

groups.

TBD

Deliverables:

TBD

Milestones:

TBD

---

From: Alper Yegin <[email-masked]>
Date: Wed, 4 Jun 2014 19:22:42 +0300

Hi Peng,

Looks good, thank you.

Alper

On Jun 4, 2014, at 4:11 PM, Fan, Peng wrote:

> Hi Alper,
>  
> Thanks for the advice. I revised the proposal a little to make it clearer, you can find the latest version athttp://tools.ietf.org/bof/trac/#Internet. We may still need to change the draft charter after further revision.
>  
> My understanding is that the short term deliverables are those background items you gathered. Then we can re-charter to enter the solution space, e.g. information that needs to be communicated between applications and the network, framework for providing such communication, protocol extension to support this framework, etc.
>  
> Best regards,
> Peng
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Jun 2014 17:31:38 +0000

Peng,

For metadata to be visible to the network, the metadata have to be carried in a header such as SFC header.
Is AEON also defining this Metadata header? Should the Metadata Header defined by AEON consistent with the Metadata defined by SFC?

I am just concerned if AEON only focus on the metadata between applications and service functions, then AEON would become a subset of SFC WG deliverables.

Linda

From: Fan, Peng [mailto:[email-masked]]
Sent: Wednesday, June 04, 2014 8:16 AM
To: Linda Dunbar; 'Tirumaleswar Reddy (tireddy)'; [email-masked]
Subject: RE: [Aeon] Charter Proposal

Hi Linda,

I am trying to understand why the metadata is not visible to network. Flow characteristics, or metadata, are conveyed to network nodes which can be a gateway, a router, or other elements that need visibility into the traffic. These nodes are not necessarily a DPI element, and are not necessarily located at the edge or center of a network. Speaking of SFC metadata I would like to know how is it related with flow characteristics we are now working on.

We have not gone that far in discussing how the characteristics are encoded and carried, though at the very early age of this work there were some drafts on this. Also I remember this minutes of the barbof at London IETF which I think is helpful in showing some of the concepts of this work http://www.ietf.org/mail-archive/web/aeon/current/msg00025.html.

Best regards,
Peng

From: Aeon [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, June 03, 2014 11:57 PM
To: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; [email-masked]<mailto:[email-masked]>
Subject: Re: [Aeon] Charter Proposal

Peng,

Linda

From: Fan, Peng [mailto:[email-masked]]
Sent: Monday, June 02, 2014 10:50 PM
To: 'Tirumaleswar Reddy (tireddy)'; Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: RE: [Aeon] Charter Proposal

Hi all,

Best regards,
Peng

-Tiru

Linda

Deliverables:
TBD

Milestones:
TBD

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 04 Jun 2014 19:28:55 -0400

Linda,

What does the metadata header look from SFC? What kind of header is this?  Is this specific to a certain protocol, a special metadata protocol, or is this a transport independent data blob that is carried inside other protocols?

Paul

-------- Original Message --------
From: Linda Dunbar <[email-masked]>
Sent: June 4, 2014 1:31:38 PM EDT
To: "Fan, Peng" <[email-masked]>, "'Tirumaleswar Reddy (tireddy)'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Aeon] Charter Proposal

Peng,

Linda

Hi Linda,

Best regards,
Peng

Peng,

Linda

Hi all,

Best regards,
Peng

-Tiru

Linda

Deliverables:
TBD

Milestones:
TBD

------------------------------------------------------------------------

---

From: Alper Yegin <[email-masked]>
Date: Thu, 5 Jun 2014 11:30:29 +0300

Hi Linda,

The metadata "may" also be communicated at the beginning of the IP flow. In other words, it does not have to be communicated on each IP packet.
So, AEON may not be just about extending SFC all the way to the terminal.

Alper

On Jun 4, 2014, at 8:31 PM, Linda Dunbar wrote:

> This is the Metadata,  which have been addressed by SFC WG. Why creating a new WG simply for Metadata? Besides, all traffic will be aggregated by the provider edge devices. The DPI/FW in the middle of the provider networks can’t even seen those metadata attached to Applications, unless using a new header such as SFC header to carry those metadata.
>  
> Linda
>  
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 5 Jun 2014 15:49:58 +0000

Alper,

Do you mean exchange Metadata via control plane or out-of-band signal? Such as today's Mobile network using Diameter to pass metadata to service functions?

Linda

From: Alper Yegin [mailto:[email-masked]]
Sent: Thursday, June 05, 2014 3:30 AM
To: Linda Dunbar
Cc: Fan, Peng; 'Tirumaleswar Reddy (tireddy)'; [email-masked]
Subject: Re: [Aeon] Charter Proposal

Hi Linda,

Alper

Peng,

Linda

From: Fan, Peng [mailto:[email-masked]]
Sent: Wednesday, June 04, 2014 8:16 AM
To: Linda Dunbar; 'Tirumaleswar Reddy (tireddy)'; [email-masked]<mailto:[email-masked]>
Subject: RE: [Aeon] Charter Proposal

Hi Linda,

Best regards,
Peng

Peng,

Linda

Hi all,

Best regards,
Peng

-Tiru

Linda

Deliverables:
TBD

Milestones:
TBD

---

From: Alper Yegin <[email-masked]>
Date: Fri, 6 Jun 2014 00:00:27 +0300

Hi Linda,

On Jun 5, 2014, at 6:49 PM, Linda Dunbar wrote:

> Alper,
>  
> Do you mean exchange Metadata via control plane or out-of-band signal?

Yes.

Alper

> Such as today’s Mobile network using Diameter to pass metadata to service functions?
>  
> Linda
>