Re: [tcmtf] New version of TCMTF reccomendations draft

[Mirko Sužnjević <[e-mail]>]

Hey all,
I have not considered adding anything regarding multiplexing ACKs for this version, because when i was rereading all the mails in the list it seemed to me that the ACK problem was not completely resolved and that consensus was not created on this issue.
But i think we can do something regarding that as well! And yes that section could be good for ACKs problem.
Cheers!
Mirko

From: Jose Saldana [mailto:[e-mail]]
Sent: Tuesday, June 11, 2013 11:21 AM
To: Mirko Sužnjević
Cc: [e-mail]
Subject: RE: [tcmtf] New version of TCMTF reccomendations draft

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

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]> [mailto:[e-mail]] En nombre de Mirko Sužnjevic
Enviado el: domingo, 09 de junio de 2013 21:39
Para: [e-mail]<mailto:[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