Re: [tcmtf] Using the concept of "latency budget" for TCM-TF

["Jose Saldana" <[e-mail]>]

Hi, Joe,

Thanks for the info. You are right.

> -----Mensaje original-----
> De: Joe Touch [mailto:[e-mail]]
> Enviado el: jueves, 06 de febrero de 2014 23:55
> Para: Jose Saldana; [e-mail]
> CC: [e-mail]
> Asunto: Re: [tcmtf] Using the concept of "latency budget" for TCM-TF
> 
> 
> 
> On 2/6/2014 1:22 AM, Jose Saldana wrote:
> > Hi all,
> >
> > The report of the Workshop on Reducing Internet Latency
> > (http://www.internetsociety.org/latency2013) talks about a very
> > interesting concept: "latency budget":
> 
> FWIW, this term is several decades old.
> 
> ...
> > 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".
> 
> 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.


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