Re: [Aeon] Charter Proposal

["Jose Saldana" <[e-mail]>]

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