Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows

If this is going to be used in the general Internet, then we need to 
decide whether there is one-way or two-way control connectivity. This 
will determine the constraints from a congestion control perspective. 
RTT and/or control feedback would be really helpful in establishing a 
congestion control or circuit-breaker function to ensure the traffic 
does not cause congestion collapse. Have you thought about this?

Gorry

On 17/01/2013 13:50, Jose Saldana wrote:
> In addition, perhaps we are too focused on online games and VoIP services. There are other services which are one-way: perhaps M2M communications do not require a two way communication. We can think about a number of sensors sending their measurements to a central server. So perhaps RTT will not even exist in this case.
>
> Jose
>
>> -----Mensaje original-----
>> De: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es]
>> Enviado el: jueves, 17 de enero de 2013 14:39
>> Para: jsaldana@unizar.es; 'Dan Wing'; 'Mirko Sužnjević'; 'Julián Fernández
>> Navajas'
>> CC: tcmtf@ietf.org
>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling
>> Compressed Multiplexed Traffic Flows
>>
>> Jose,
>>
>>          Let´s say that playing with the OWD you have more granularity in order to
>> know in which direction you need to reduce the delay by reducing the
>> multiplexing delay. But people with more knowledge about online games will
>> provide us more information for sure.
>>
>> Regards,
>>
>> Fernando Pascual Blanco
>> Telefónica Global Resources
>> Network Automation and Dynamization
>> TECHNOLOGY PEOPLE GROUP
>> F +34913128779
>> M +34682005168
>> fpb@tid.es
>>
>>
>>
>>
>> On 17/01/13 13:16, "Jose Saldana" <jsaldana@unizar.es> wrote:
>>
>>> Fernando,
>>>
>>> So you may have this case:
>>> - your multiplexing delay limit is 50 ms
>>> - you have a lot of flows to multiplex, so perhaps the time between
>>> multiplexed packets will be 5 ms
>>> - you detect an increase in RTT
>>> - the system reacts and reduces multiplexing period
>>> - in fact, the reduction doesn't matter until the period is reduced to
>>> less than 5 ms
>>>
>>> So you only have to make this decision: using tcmtf with 5 ms period or
>>> not. If RTT is critical you may not be interested on saving bandwidth,
>>> but on reducing a bit the RTT.
>>>
>>> So I think your question is: what happens if the RTT is very big (out
>>> of
>>> limits) and you can save bandwidth using a 5ms multiplexing period?
>>>
>>> For example, the maximum RTT for a good quality is 80 ms and your
>>> network has 120 just now. In this case, perhaps having 125 doesn't
>>> matter, if you can save bandwidth.
>>>
>>> This makes sense, but it is a "extreme" case. However, would it be any
>>> advantage if OWD is used instead of RTT?
>>>
>>> Best regards,
>>>
>>> Jose
>>>
>>>> -----Mensaje original-----
>>>> De: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es]  Enviado el:
>>>> miércoles, 16 de enero de 2013 12:52
>>>> Para: jsaldana@unizar.es; 'Dan Wing'; 'Mirko Sužnjević'; 'Julián
>>>> Fernández  Navajas'
>>>> CC: tcmtf@ietf.org
>>>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
>>>> Tunneling  Compressed Multiplexed Traffic Flows
>>>>
>>>> Hi Jose,
>>>>
>>>>          You are right, but my point here is:
>>>>
>>>>                  Client - Mux - Demux - Server
>>>>
>>>>          Imagine that there is enough packets between mux and demux to
>>>> make  the added delay very small (TCMTF is working very well and the
>>>> mux has not  to wait the multiplexing period to fulfill a big packet
>>>> and send it, so imagine a  multiplexing period of 50 ms and a big
>>>> packet is fulfilled in 5 ms). If the RTT  get increased because a
>>>> congestion in the way back to the client (there is no  TCMTF
>>>> optimization) and we decrease the multiplexing period (even in the
>>>> extreme we can disable the TCMTF optimization) the high RTT will remain.
>>>> Even if the TCMTF optimization was helping in the client to server
>>>> path,  disabling it may harm. Do you think that scenario would be possible?
>>>>
>>>>          So I´m not sure about that, I think we need more opinions here.
>>>>
>>>> Regards,
>>>>
>>>> Fernando Pascual Blanco
>>>> Telefónica Global Resources
>>>> Network Automation and Dynamization
>>>> TECHNOLOGY PEOPLE GROUP
>>>> F +34913128779
>>>> M +34682005168
>>>> fpb@tid.es
>>>>
>>>>
>>>>
>>>>
>>>> On 16/01/13 11:57, "Jose Saldana" <jsaldana@unizar.es> wrote:
>>>>
>>>>> My two cents:
>>>>>
>>>>> In games and in VoIP the really important thing is RTT:
>>>>>
>>>>> - Games always measure the RTT (gamers talk about the "ping"): the
>>>>> important thing is the delay from a player action to the server
>>>>> reaction arriving to the player's machine.
>>>>> - In VoIP I think it is the same: what matters is the RTT, in order
>>>>> to grant interactivity and avoiding cross-talk.
>>>>>
>>>>> In addition, RTT is easier to measure than OWD, since you don't need
>>>>> synchronization.
>>>>>
>>>>> And regarding Two-way TCMTF, I think we have to think about TCMTF as
>>>>> one-way. Otherwise, things would become very complicated. Some
>>>> services
>>>>> have very different client-server and server-client traffic patterns
>>>>> (e.g. games). In addition, sometimes the two flows can follow
>>>>> different network paths. I think once we talked about a network
>>>>> provider using a number of ISPs.
>>>>>
>>>>> However, using RTT for tuning a one-way TCMTF may not be bad... or
>>>>> is it bad? Any other thoughts?
>>>>>
>>>>> BR,
>>>>>
>>>>> Jose
>>>>>
>>>>>> -----Mensaje original-----
>>>>>> De: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es]  Enviado el:
>>>> martes,
>>>>>> 15 de enero de 2013 18:04
>>>>>> Para: jsaldana@unizar.es; 'Dan Wing'; 'Mirko Sužnjević'; Julián
>>>>>> Fernández  Navajas
>>>>>> CC: tcmtf@ietf.org
>>>>>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
>>>>>> Tunneling  Compressed Multiplexed Traffic Flows
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>>          To re-open that issue, I would suggest that given that the
>>>>>> delay is so  sensitive in real time services, we need to find a
>>>>>> consensus here.
>>>>>>
>>>>>>          My opinion is that to apply the first possibility (the
>>>>>> static multiplexing
>>>>>> period) we need to suppose that the network conditions are really
>>>>>> bad, to be  protected when the network congestion arises. In that
>>>>>> case, the application  of the TCMTF optimization will not be
>>>>>> optimal, so that would be the less  preferred option, but easier to
>>>>>> implement and maintain over the time.
>>>>>>
>>>>>>          On the other hand, the second possibility would be the
>>>>>> preferred. It is  easy to know the delay between the mux and the
>>>>>> demux but most of the  times will not be enough unless mux and
>>>>>> demux were really near from the  client and the server
>>>>>> respectively. I agree with Jose in the possibility of snoop  RTCP
>>>>>> packets in order to adapt the multiplexing period when multiplexing
>>>>>> RTP packets (and RTCP is available). Talking about RTT, I´m not
>>>>>> sure if RTT  would be useful given that the multiplexing period
>>>>>> only affect the one way  delay (OWD). Imagine the following scenario:
>>>>>>          - Client - Mux/Demux - Demux/Mux - Server (two ways TCMTF,
>>>>>> TWTCMTF :P)
>>>>>>          - The OWD from server to client get increased
>>>>>>          - The OWD from client to server remains equal
>>>>>>          - Should we use a lower multiplexing period in the client
>>>>>> to server  direction? I don´t think so… because we should use a
>>>>>> lower multiplexing  period in the other direction.
>>>>>>
>>>>>>          My point is that the multiplexing period should only be
>>>>>> affected by the  OWD and not by the RTT (or it may be application
>>>>>> dependent). How to  calculate the OWD? I´ve been reading something
>>>>>> about OWAMP and it  seems that an specific software has to be
>>>>>> implemented in the client/server  side.
>>>>>> Can we assume that? Unfortunately I cannot contribute so much
>> here…
>>>>>>          It is possible that for certain services the static (and
>>>>>> worst
>>>>>> case)
>>>>>> multiplexing period would be the better solution.
>>>>>>
>>>>>>          What do you think?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Fernando Pascual Blanco
>>>>>> Telefónica Global Resources
>>>>>> Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP
>> F
>>>>>> +34913128779 M +34682005168 fpb@tid.es
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 17/12/12 12:25, "Jose Saldana" <jsaldana@unizar.es> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Julian and I have been discussing about this. Some ideas have
>>>> arisen.
>>>>>>> This is the summary.
>>>>>>>
>>>>>>> This would be the scheme of the system, including mux and demux:
>>>>>>>
>>>>>>> Real-time application ------- mux -------- internet ---------
>>>>>>> demux
>>>>>>> -------
>>>>>>> server
>>>>>>>
>>>>>>>
>>>>>>> I think perhaps the draft could say something like:
>>>>>>>
>>>>>>> When setting the multiplexing period, there are two possibilities:
>>>>>>>
>>>>>>> 1.- Static / permanent: At system setup time, network delays are
>>>>>>> measured, and a multiplexing period is selected and set in the
>>>>>> multiplexer.
>>>>>>>
>>>>>>> 2.- Dynamic: A mechanism is used so as to adapt to the evolution
>>>>>>> of network delays. In this case, different mechanisms can be used
>>>>>>> in order to obtain periodical end-to-end network delay
>>>>>>> estimations, which would be useful in order to set the multiplexing
>> period:
>>>>>>>
>>>>>>> - If the traffic is RTP, then RTCP packets containing the
>>>>>>> estimation could be analyzed in order to extract these values, as Dan
>> suggests.
>>>>>>> The question
>>>>>>> is: would that packets travel through the multiplexer?
>>>>>>> - If the traffic is TCP, perhaps something similar to the RTT
>>>>>>> estimation of TCP could be useful.
>>>>>>> - If the traffic is UDP, should the mux use something like OWAMP
>>>>>>> (http://tools.ietf.org/html/rfc4656) in order to calculate two
>>>>>>> delays (application to mux, and mux to server) and calculate the
>>>> sum?
>>>>>>>
>>>>>>>
>>>>>>> I think the draft is only supposed to report the maximum delays
>>>>>>> normally considered acceptable. Perhaps the additional mechanisms
>>>>>>> for calculating the RTT could just be suggested.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Jose
>>>>>>>
>>>>>>>> -----Mensaje original-----
>>>>>>>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En
>>>>>>>> nombre de Dan Wing Enviado el: viernes, 14 de diciembre de 2012
>>>>>>>> 18:33
>>>>>>>> Para: jsaldana@unizar.es; 'Mirko Sužnjević'
>>>>>>>> CC: tcmtf@ietf.org
>>>>>>>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
>>>>>>>> Tunneling Compressed Multiplexed Traffic Flows
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Jose Saldana [mailto:jsaldana@unizar.es]
>>>>>>>>> Sent: Friday, December 14, 2012 2:58 AM
>>>>>>>>> To: 'Dan Wing'; 'Mirko Sužnjević'
>>>>>>>>> Cc: tcmtf@ietf.org
>>>>>>>>> Subject: RE: [tcmtf] Draft: Maximum Tolerable Delays when
>>>>>>>>> using Tunneling Compressed Multiplexed Traffic Flows
>>>>>>>>>
>>>>>>>>> Dan,
>>>>>>>>>
>>>>>>>>> Regarding the use of the maximum delay, some days ago we
>>>>>>>>> discussed about
>>>>>>>>> it:
>>>>>>>>> the actual OWD of the network should be measured (or
>>>>>>>>> estimated) in order to know the maximum multiplexing period we
>> can set.
>>>>>>>>>
>>>>>>>>> We may have this formula, if thinking one-way:
>>>>>>>>>
>>>>>>>>> OWD  + Mux period/2  < tolerable_OWD
>>>>>>>>>
>>>>>>>>> If we think RTT:
>>>>>>>>>
>>>>>>>>> OWD + Mux period/2 + OWD back < 2*tolerable_OWD
>>>>>>>>>
>>>>>>>>> I don't know if we should include a mechanism for estimating
>>>>>>>>> OWD in tcmtf. I think this is more an implementation problem,
>>>>>>>>> which may be already solved.
>>>>>>>>
>>>>>>>> Yes, it's already solved end-to-end:  RTP with RTCP feedback
>>>>>>>> allows determining one way delay.
>>>>>>>>
>>>>>>>> But if something in the middle is multiplexing several packets
>>>>>>>> together,
>>>>>>> we
>>>>>>>> don't want it to add too much delay.  That thing in the middle
>>>>>>>> won't necessarily know the one way delay seen by the endpoints,
>>>>>>>> unless it analyzes the RTP and RTCP.  There are devices that do
>>>>>>>> that on the market,  mostly to diagnose where networks are
>>>>>>>> causing loss/delay with RTP flows.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Another option is using some typical values, e.g. from
>>>>>>>>>
>> http://ipnetwork.bgtmo.ip.att.net/pws/global_network_avgs.htm
>>>>>>>>> l
>>>>>>>>>
>>>>>>>>> The draft includes some preliminary/recommended values for
>>>>>>>>> the Multiplexing Period. Is this interesting? Should we put
>>>>>>>>> the formula instead?
>>>>>>>>
>>>>>>>> It's probably sufficient as-is.
>>>>>>>>
>>>>>>>> -d
>>>>>>>>
>>>>>>>>> Mirko, another question: in online games, players usually
>>>>>>>>> talk about the "ping", and I think it means RTT. Don't you
>>>>>>>>> think it would be better to define a RTT limit instead of a
>>>>>>>>> OWD one in that
>>>>>> case?
>>>>>>>>>
>>>>>>>>> What do you think?
>>>>>>>>>
>>>>>>>>> Jose
>>>>>>>>>
>>>>>>>>>> -----Mensaje original-----
>>>>>>>>>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org]
>>>>>>>>>> En nombre de Dan Wing Enviado el: jueves, 13 de diciembre
>>>>>>>>>> de 2012
>>>>>>>>>> 17:07
>>>>>>>>>> Para: 'Mirko Sužnjević'; tcmtf@ietf.org
>>>>>>>>>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when
>>>>>>>>>> using Tunneling Compressed Multiplexed Traffic Flows
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: tcmtf-bounces@ietf.org
>>>>>>>>>>> [mailto:tcmtf-bounces@ietf.org] On Behalf Of Mirko
>>>>>>>>>>> Sužnjevic
>>>>>>>>>>> Sent: Thursday, December 13, 2012 1:07 AM
>>>>>>>>>>> To: tcmtf@ietf.org; tsvwg@ietf.org
>>>>>>>>>>> Subject: [tcmtf] Draft: Maximum Tolerable Delays when
>>>>>>>>>>> using Tunneling Compressed Multiplexed Traffic Flows
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We have just submitted the draft named Maximum Tolerable
>>>>>>>>>>> Delays when using Tunneling Compressed Multiplexed
>>>>>>>>>>> Traffic
>>>> Flows:
>>>>>>>>>>> http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd
>>>>>>>>>>> -tc
>>>>>>>>>>> mtf
>>>>>>>>>>> /
>>>>>>>>>>
>>>>>>>>>> The suggested 400ms for interactive voice is at least 2x
>>>>>>>>>> too
>>>>>> high.
>>>>>>>>>> I
>>>>>>>>> expect
>>>>>>>>>> that number does not include the playout jitter buffer
>>>>>>>>>> (which is variable,
>>>>>>>>> but
>>>>>>>>>> usually a few samples, so 40-80ms).  200ms end-to-end is
>>>>>>>>>> the higher end,
>>>>>>>>> and
>>>>>>>>>> that includes jitter buffer, codec processing, and so on.
>>>>>>>>>>
>>>>>>>>>> But, more importantly:  it seems valuable for endpoints to
>>>>>>>>>> signal their maximum delay somehow.  Or would the TCMTF
>>>>>>>>>> function
>>>>>>>> determine
>>>>>>>>>> the maximum delay, using some heuristic?
>>>>>>>>>>
>>>>>>>>>> How does the TCMTF function determine how much of that
>>>>>>>>>> 'tolerable latency' budget it can consume?
>>>>>>>>>>
>>>>>>>>>> -d
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> It is an extension of tcmtf
>>>>>>>>>>> http://datatracker.ietf.org/doc/draft-
>>>>>>>>>>> saldana-tsvwg-tcmtf/. Since a specific list for tcmtf
>>>>>>>>>>> exists (tcmtf@ietf.org), the idea is to discuss it there.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The draft contains recommendations for TCMTF multiplexing
>>>>>>>>>>> period for different real-time services. In order to
>>>>>>>>>>> prevent QoE degradation of real-time services using
>>>>>>>>>>> TCMTF, a policy defining a multiplexing period can be
>>>>>>>>>>> employed. Values of maximum tolerable delays presented in
>>>>>>>>>> the
>>>>>>>>>>> draft form the base of such policy.    The recommendations
>>>> are
>>>>>>>>> presented
>>>>>>>>>>> for real-time network services in which TCTMF bandwidth
>>>>>>>>>>> optimization is applicable (i.e., services  which have
>>>>>>>>>>> low payload to header size ratio which results in high
>>>>>>>>>>> protocol
>>>>>> overhead).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Your feedback will be welcome. Thank you.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Sincerely,
>>>>>>>>>>>
>>>>>>>>>>> Mirko Suznjevic
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> tcmtf mailing list
>>>>>>>>>> tcmtf@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> tcmtf mailing list
>>>>>>>> tcmtf@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> tcmtf mailing list
>>>>>>> tcmtf@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>>>>>
>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede
>>>>>> consultar nuestra política de envío y recepción de correo
>>>>>> electrónico en el enlace situado más abajo.
>>>>>> This message is intended exclusively for its addressee. We only
>>>>>> send and receive email on the basis of the terms set out at:
>>>>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>>>>
>>>>> _______________________________________________
>>>>> tcmtf mailing list
>>>>> tcmtf@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede
>>>> consultar nuestra política de envío y recepción de correo electrónico
>>>> en el enlace situado más abajo.
>>>> This message is intended exclusively for its addressee. We only send
>>>> and receive email on the basis of the terms set out at:
>>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>>
>>
>>
>> ________________________________
>>
>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>> nuestra política de envío y recepción de correo electrónico en el enlace
>> situado más abajo.
>> This message is intended exclusively for its addressee. We only send and
>> receive email on the basis of the terms set out at:
>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
> _______________________________________________
> tcmtf mailing list
> tcmtf@ietf.org
> https://www.ietf.org/mailman/listinfo/tcmtf
>