Re: [Aeon] Charter Proposal

["Fan, Peng" <[e-mail]>]

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:[e-mail]] On Behalf Of Jose Saldana
Sent: Tuesday, June 03, 2014 4:52 PM
To: 'Linda Dunbar'; [e-mail]
Subject: Re: [Aeon] Charter Proposal

 

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:[e-mail]] En nombre de Linda Dunbar
Enviado el: lunes, 02 de junio de 2014 0:03
Para: [e-mail]
Asunto: Re: [Aeon] Charter Proposal

 

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