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:
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
--
Richard Bennett
Visiting Fellow, American Enterprise Institute
Center for Internet, Communications, and Technology Policy
Editor, High Tech Forum
