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

[FERNANDO PASCUAL BLANCO <[e-mail]>]

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 [phone]
M [phone]
[e-mail]




On 17/12/12 12:25, "Jose Saldana" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] En nombre de
>> Dan Wing
>> Enviado el: viernes, 14 de diciembre de 2012 18:33
>> Para: [e-mail]; 'Mirko Sužnjević'
>> CC: [e-mail]
>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling
>> Compressed Multiplexed Traffic Flows
>>
>> > -----Original Message-----
>> > From: Jose Saldana [mailto:[e-mail]]
>> > Sent: Friday, December 14, 2012 2:58 AM
>> > To: 'Dan Wing'; 'Mirko Sužnjević'
>> > Cc: [e-mail]
>> > 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.html
>> >
>> > 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: [e-mail] [mailto:[e-mail]] En nombre
>> > > de Dan Wing Enviado el: jueves, 13 de diciembre de 2012 17:07
>> > > Para: 'Mirko Sužnjević'; [e-mail]
>> > > Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
>> > > Tunneling Compressed Multiplexed Traffic Flows
>> > >
>> > > > -----Original Message-----
>> > > > From: [e-mail] [mailto:[e-mail]] On
>> > > > Behalf Of Mirko Sužnjevic
>> > > > Sent: Thursday, December 13, 2012 1:07 AM
>> > > > To: [e-mail]; [e-mail]
>> > > > 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-tcmtf/
>> > >
>> > > 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
>> > > > ([e-mail]), 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
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/tcmtf
>>
>> _______________________________________________
>> tcmtf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcmtf
>
>_______________________________________________
>tcmtf mailing list
>[e-mail]
>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