Subject: [tcmtf] New version of TCMTF reccomendations draft

From: Mirko Sužnjević <[email-masked]>
Date: Sun, 9 Jun 2013 19:38:36 +0000

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

---

From: Julián Fernández-Navajas <[email-masked]>
Date: Mon, 10 Jun 2013 17:00:44 +0200

Mirko,
I thank you for the changes scheme. I have seen better the improvements.
I agree with these changes.

Julián Fernández-Navajas

  El 09/06/2013 21:38, Mirko Sužnjevic' escribió:
>
> 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
>
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 11 Jun 2013 11:21:00 +0200

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

Moderate changes:

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

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

Best regards,

Mirko Suznjevic

---

From: Mirko Sužnjević <[email-masked]>
Date: Tue, 11 Jun 2013 10:57:56 +0000

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:[email-masked]]
Sent: Tuesday, June 11, 2013 11:21 AM
To: Mirko Sužnjević
Cc: [email-masked]
Subject: RE: [tcmtf] New version of TCMTF reccomendations draft

Mirko,

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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] En nombre de Mirko Sužnjevic
Enviado el: domingo, 09 de junio de 2013 21:39
Para: [email-masked]<mailto:[email-masked]>
Asunto: [tcmtf] New version of TCMTF reccomendations draft

Hello everybody,

Major changes:

Moderate changes:

Minor changes: