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.
Joe
