Subject: Using the concept of "latency budget" for TCM-TF

From: "Jose Saldana" <[email-masked]>
Date: Thu, 6 Feb 2014 10:22:33 +0100

Hi all,
 
The report of the Workshop on Reducing Internet Latency
(http://www.internetsociety.org/latency2013) talks about a very interesting
concept: "latency budget":
 
"A latency budget is applicable to the application and is consumed by
sources of latency."
"Latency budgets can be hard or soft and may be derived from biological or
computational expectations."
"The application operates effectively only when the cost is kept within the
budget."
 
Since TCM-TF savings require the addition of an small latency as a
counterpart, perhaps we could say something like "if an amount of latency
budget is available, a part of it can be consumed in multiplexing packets,
thus providing bandwidth savings".
 
And some sentences of the draft about delay limits could even be rewritten
accordingly: for example, instead of talking about "delay recommendations"
in section 6, we could talk about "latency budget" for each application.
 
What do you think?
 
Best regards,
 
Jose

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Feb 2014 14:54:39 -0800

On 2/6/2014 1:22 AM, Jose Saldana wrote:
> (http://www.internetsociety.org/latency2013) talks about a very
> interesting concept: “latency budget”:

FWIW, this term is several decades old.

...
> counterpart, perhaps we could say something like “if an amount of
> latency budget is available, a part of it can be consumed in
> multiplexing packets, thus providing bandwidth savings”.

That's true for any aggregation protocol. There are overheads - 
processing, latency, storage - which presumably are reasonable costs in 
exchange for benefits elsewhere (e.g., bandwidth savings in this case).

> And some sentences of the draft about delay limits could even be
> rewritten accordingly: for example, instead of talking about “delay
> recommendations” in section 6, we could talk about “latency budget” for
> each application.

The latency budget of an application is easier to define and understand, 
but the other ways in which this budget is consumed aren't under your 
control.

I.e., you can't always say that "X has a budget of 100ms" and then 
conclude that *any* of that budget is available for you to consume. 
There are simply too many other competing consumers of that budget - 
propagation, queuing, transcoding, rendering, encoding, etc.

In summary, everything you've said is true, but it's equally true for 
any other protocol, and so I don't see the value here in highlighting it.

Joe

---

From: Richard Bennett <[email-masked]>
Date: Thu, 06 Feb 2014 14:58:09 -0800

It's often useful to think about TTL in terms of latency rather that hops.

On 2/6/14, 2:54 PM, Joe Touch wrote:
> processing, latency, storage - which presumably are reasonable costs 
> in exchange for benefits elsewhere (e.g., bandwidth savings in this 
> case).
>
> The latency budget of an application is easier to define and 
> understand, but the other ways in which this budget is consumed aren't 
> under your control.
>

-- 
Richard Bennett
Visiting Fellow, American Enterprise Institute
Center for Internet, Communications, and Technology Policy
Editor, High Tech Forum

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Feb 2014 15:18:19 -0800

> It's often useful to think about TTL in terms of latency rather that hops.

Except that the two are not related.

Originally, the TTL was supposed to be decremented by one for each 
second a router held a packet, with a minimum of one.

Because few routers hold packets anywhere close to a second, it has 
devolved to mean just the number of routers in the path, although it 
also is used to engineer preference for different paths.

Overall, it doesn't represent latency well.

Joe

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 7 Feb 2014 09:44:16 +0100

Hi, Joe,

Thanks for the info. You are right.

> -----Mensaje original-----
> De: Joe Touch [mailto:[email-masked]]
> Enviado el: jueves, 06 de febrero de 2014 23:55
> Para: Jose Saldana; [email-masked]
> CC: [email-masked]
> Asunto: Re: [tcmtf] Using the concept of "latency budget" for TCM-TF
> 
> 
> 
> > interesting concept: "latency budget":
> 
> > counterpart, perhaps we could say something like "if an amount of
> > multiplexing packets, thus providing bandwidth savings".
> 
processing,
> latency, storage - which presumably are reasonable costs in exchange for
> benefits elsewhere (e.g., bandwidth savings in this case).
> 
> > rewritten accordingly: for example, instead of talking about "delay
> > recommendations" in section 6, we could talk about "latency budget"
> > for each application.
> 
but
> the other ways in which this budget is consumed aren't under your control.
> 
conclude
> that *any* of that budget is available for you to consume.
> In summary, everything you've said is true, but it's equally true for any
other
> protocol, and so I don't see the value here in highlighting it.

The only question that is different in TCM-TF is that we have to multiplex
packets, so for certain services we must define a "multiplexing period" (the
added delay is half the period in average). In this case, we can control
this portion of the added delay. We can tune the period if the latency gets
modified.

This is why I thought that was interesting here: we can control and tune a
part of the latency in this case.

> Joe

Thanks!

Jose

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 10 Feb 2014 16:37:45 +0100

Hi,

On 7 Feb. 2014, at 09:44 , Jose Saldana <[email-masked]> wrote:

[snip]
> this portion of the added delay. We can tune the period if the latency gets

Will this be documented in the documents produced by the WG? 

I mean, it would be useful to have something that describes performances with different multiplexing period and may be a recommended setup depending of the traffic type (e.g. gaming vs voip).

What do you think?

L.

> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 18 Feb 2014 09:45:20 +0100

Sure.

We have studied the effect of the added delay (and jitter) on different
services: VoIP, games. We have even used subjective quality estimators in
order to see the degradation as a function of the period.

We can include some ideas in the second draft (Delay Limits and Multiplexing
Policies to be employed with Tunneling Compressed Multiplexed Traffic Flows,
http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

Thanks,

Jose
PS:
A paper about the effect on VoIP:

Jose Saldana, Julian Fernandez-Navajas, Jose Ruiz-Mas, Jenifer Murillo,
Eduardo Viruete, Jose I. Aznar, "Evaluating the Influence of Multiplexing
Schemes and Buffer Implementation on Perceived VoIP Conversation Quality,"
Computer Networks (Elsevier), Volume 56, Issue 7, Pages 1893-1919, May 2012.
doi 10.1016/j.comnet.2012.02.004

Another one about the effect on a game:

Jose Saldana, Julian Fernandez-Navajas, Jose Ruiz-Mas, Eduardo Viruete
Navarro, Luis Casadesus, "Online FPS Games: Effect of Router Buffer and
Multiplexing Techniques on Subjective Quality Estimators," Multimedia Tools
and Applications, Springer. doi 10.1007/s11042-012-1309-4

> De: Luigi Iannone [mailto:[email-masked]]
> Enviado el: lunes, 10 de febrero de 2014 16:38
> Para: Jose Saldana
> CC: Joe Touch; [email-masked]; [email-masked]
> > The only question that is different in TCM-TF is that we have to
> > multiplex packets, so for certain services we must define a
> > "multiplexing period" (the added delay is half the period in average).
> > In this case, we can control this portion of the added delay. We can
> > tune the period if the latency gets modified.
> >
> 
> I mean, it would be useful to have something that describes performances
> with different multiplexing period and may be a recommended setup
> depending of the traffic type (e.g. gaming vs voip).
> 
> What do you think?
> 
> L.
> 
> 
> 
> > This is why I thought that was interesting here: we can control and
> > tune a part of the latency in this case.
> >
> >>
> >> Joe
> >
> > Thanks!
> >
> > Jose
> >

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Feb 2014 10:20:51 -0800

> order to see the degradation as a function of the period.

There's several decades of work - much of this ongoing - studying this 
effect. You might look into it and cite some of the existing understanding.

> http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

AFAICT, this implies you assume that the HCI latency budget is yours to 
consume; you need to account for the rest of the system.

Joe