Re: [tcmtf] New version of TCMTF reccomendations draft

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

Mirko,

 

I agree with your suggestions (great job!)

 

Just a minor comment:

 

Are you considering the idea of multiplexing ACKs flows? As we discussed,
when you are e.g. downloading a file, a laptop may send 125 ACks per second.
And they have a lot of redundant headers. Perhaps we could just announce the
idea. Of course, ACKs of a download are not "real-time", but if you add too
much delay, the throughput can be reduced. This idea was suggested by
Michael some weeks ago:
<http://www.ietf.org/mail-archive/web/tcmtf/current/msg00235.html>
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00235.html

 

We could perhaps announce this in "Addition of limitations for non-real time
services such as Web browsing": we could also talk about the problem of
additional delays in the ACKs when you are downloading a file, not only in
web browsing.

 

What do you think?

 

Jose

 

De: [e-mail] [mailto:[e-mail]] En nombre de
Mirko Sužnjevic
Enviado el: domingo, 09 de junio de 2013 21:39
Para: [e-mail]
Asunto: [tcmtf] New version of TCMTF reccomendations draft

 

Hello everybody,

I am creating a new version of the TCMTF - recommendations document. In this
mail I will include all the changes which I am including in this version of
the document. These changes were suggested on this mailing list as well as
by some other sources.

Please if anyone has anything more to add say so now! Or wait till the next
version ;) I will submit the new version by 15.6.

 

Major changes:

1)      Briefly describe traffic flow identification problem (i.e., which
flows should be TCMTFed) and possible solutions

2)      Addition of  available traffic classification methods which can be
used by TCMTF (i.e., when we know which flow can be TCMTFed assigning it to
a proper multiplexing period)

3)      Addition of limitations for non-real time services such as Web
browsing

4)      Description of the policies for multiplexing period and possible
ways to measure delay

5)      Inclusion of the discussion regarding jitter buffers for VoIP and as
well to codec delay

6)      Modifying the suggested values for VoIP based on a user acceptance
level, jitter buffers, and codec delay

7)      Addition of the summary section

 

Moderate changes:

1)      Improved definition of the multiplexing period

2)      Clarification of the latency values that can be added with TCMTF

 

Minor changes:

1)      Noting that these recommendations are mostly focused on low speed
links as on high speed links the added delay should be only few ms

2)      Clarification of sentence: "Therefore, we neither take into account
services using an approach in which all the calculations are deployed in the
server, which sends a real-time video stream to the client."  In a way that
it more clearly reflects the fact that we are not addressing the cloud based
gaming services which basically stream video which has large packets

3)      Replacing "priority" with "delay sensitive class"

4)      Properly formalizing some terms: replacing "jitter" with "delay
variation" as defined in RFC 5481, and using the definition of QoE from RFC
6390

Also some other minor changes and typo corrections.

 

Thanks again to everyone who provided feedback!

Best regards,

Mirko Suznjevic