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

"Jose Saldana" <jsaldana@unizar.es> Fri, 07 February 2014 08:44 UTC

Return-Path: <jsaldana@unizar.es>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99F91A05C7; Fri, 7 Feb 2014 00:44:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Level:
X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEQqxlQLdqil; Fri, 7 Feb 2014 00:44:13 -0800 (PST)
Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 59FA41A039F; Fri, 7 Feb 2014 00:44:13 -0800 (PST)
Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s178i9hp007663; Fri, 7 Feb 2014 09:44:09 +0100
From: "Jose Saldana" <jsaldana@unizar.es>
To: "'Joe Touch'" <touch@isi.edu>, <tcmtf@ietf.org>
References: <007601cf231c$f7c78be0$e756a3a0$@unizar.es> <52F412AF.5030203@isi.edu>
In-Reply-To: <52F412AF.5030203@isi.edu>
Date: Fri, 7 Feb 2014 09:44:16 +0100
Message-ID: <006f01cf23e0$c926bf80$5b743e80$@unizar.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHPuVkuoGxnd6nNfAS2ET+wNDYJAwLz5ck/mpCtzDA=
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc: tsv-area@ietf.org
Subject: Re: [tcmtf] Using the concept of "latency budget" for TCM-TF
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf/>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 08:44:16 -0000

Hi, Joe,

Thanks for the info. You are right.

> -----Mensaje original-----
> De: Joe Touch [mailto:touch@isi.edu]
> Enviado el: jueves, 06 de febrero de 2014 23:55
> Para: Jose Saldana; tcmtf@ietf.org
> CC: tsv-area@ietf.org
> 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