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

From: "Jose Saldana" <[email-masked]>
Date: Wed, 5 Feb 2014 13:06:59 +0100

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