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

Joe Touch <> Thu, 06 February 2014 22:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 42E7D1A050D; Thu, 6 Feb 2014 14:55:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hh0173AK0c49; Thu, 6 Feb 2014 14:54:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4942D1A0511; Thu, 6 Feb 2014 14:54:58 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s16MscN6029804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Feb 2014 14:54:38 -0800 (PST)
Message-ID: <>
Date: Thu, 06 Feb 2014 14:54:39 -0800
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Jose Saldana <>,
References: <007601cf231c$f7c78be0$e756a3a0$>
In-Reply-To: <007601cf231c$f7c78be0$e756a3a0$>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [tcmtf] Using the concept of "latency budget" for TCM-TF
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Feb 2014 22:55:00 -0000

On 2/6/2014 1:22 AM, Jose Saldana wrote:
> Hi all,
> The report of the Workshop on Reducing Internet Latency
> ( 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 

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.