[tcmtf] Improvements in TCM-TF according to the received comments: Problem 3: additional delays

"Jose Saldana" <jsaldana@unizar.es> Wed, 05 February 2014 12:06 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 C052D1A00F1; Wed, 5 Feb 2014 04:06:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.021
X-Spam-Level:
X-Spam-Status: No, score=-4.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, ONE_TIME=0.714, 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 lyGb5Xl0fDFG; Wed, 5 Feb 2014 04:06:58 -0800 (PST)
Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id E2E821A00EF; Wed, 5 Feb 2014 04:06:56 -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 s15C6rHi013847; Wed, 5 Feb 2014 13:06:54 +0100
From: "Jose Saldana" <jsaldana@unizar.es>
To: <tcmtf@ietf.org>
Date: Wed, 5 Feb 2014 13:06:59 +0100
Message-ID: <009801cf226a$c5aed1c0$510c7540$@unizar.es>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01CF2273.27744B30"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac8iaHBj1FpJQ/1NReqDF17hX0AThQ==
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc: tsv-area@ietf.org
Subject: [tcmtf] Improvements in TCM-TF according to the received comments: Problem 3: additional delays
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: Wed, 05 Feb 2014 12:06:59 -0000

Problem:
 
Are we adding latency and complexity to save relatively little bandwidth?
Bob Briscoe: (.) "I am concerned about adding latency and complexity to save
relatively little bandwidth - when there will be a need for checking the
network path."
Tim Chown: "bufferbloat - could be increasing buffers to group packets up."
 
 
The answer is related to the idea of TCM-TF itself: it is summarized in n.4
of the charter draft:
 
4. New scenarios where bandwidth savings are desirable have been identified,
in addition to those considered in RFC4170. In these scenarios, there are
moments or places where network capacity gets scarce, so allocating more
bandwidth is a possible solution, but it implies a recurring cost. However,
the inclusion of a pair of boxes able to optimize the traffic when/where
required is a one-time investment.
 
In addition, the second draft is about additional delay limits. If you have
some "delay budget" available, you can use it.
 
R. Peon: "application can sometimes send multiple packets with the same
message so that they have unique probability of loss (not correlated), this
is an application choice that needs to be known by a tunnel."
 
The idea is that a tunnel does not include a number of packets from the same
flow, but from different ones.
 
Jose