Subject: Re: [tsv-area] [tana] [Fwd: Re: [p2pi] TANA proposed charter]

From: Caitlin Bestler <[email-masked]>
Date: Thu, 23 Oct 2008 09:13:38 -0700

[email-masked] wrote:

> 
> Just an interesting aside for people with a more economics mindset.
> Traditional TCP is optimised for trying to get the best instantaneous
> throughput and thus is suited to those applications where the utility is
> related to the instantaneous bandwidth you receive (e.g. streaming media
> and short data transfers). By contrast with any bulk data transfer, the
> utility you get is related to the completion time for receiving the
> file. Assuming you are reasonably rational and don't expect to receive
> files instantaneously there will be a rough time in your head by which
> you want the file delivered. This seems to make traditional TCP
> unsuitable for such transfers. In effect I think the formation of this
> WG is demonstrating that many of us understand this even if we don't
> express it in these terms.
> 

This is a very good description of the true target. The description of
"less than best effort" ignores the fact that there *is* a desired
deadline for delivery.

What characterizes the target traffic class is that it is very tolerant
about *when* its payload is delivered, as long as the entire transfer
occurs before the deadline. Traditional TCP wants its data transferred
ASAP. Rate controlled streams want a jitter-controlled stream that has
well defined rate characteristics.

Those points lead to some immediate charter issues.

- Does this traffic class *always* yield to TCP traffic, or can it have
   an underlying minimum guaranteed rate? That is, the opportunistic
   scheduling applies to delivering 'early' when possible.

   Most networks are configured with a high peak to sustained ratio, so
   delay-tolerant traffic will seldom have difficulty in being delivered
   within the desired tolerances (given the correct active queue
   management algorithms). But for some applications the deadline
   is critical -- daily backups MUST complete within so many hours.
   Any RFC that failed to address the need for *some* guarantees would
   guarantee that the protocol was used only peer-to-peer traffic, and
   exclude potentially larger applications that are also haver a lot of
   patience, it's just that their patience *is* finite.

- How does this inter-relate with L2 traffic shaping (as in 802.1
   Data Center Bridging)? Many of the applications that are potentially
   delay tolerant are Data Center-heavy and *could* live with L2-only
   traffic shaping. A solution which imposes a completely orthogonal
   control loop over the same traffic, without any form of correlation,
   will *not* produce desirable results. If the desire is to deal *only*
   with long–haul connections (i.e. those involving at least one router)
   then not dealing with L2 would be legitimate, but that should be
   explicitly stated in the charter or applicability statement.
   Creating *two* control mechanisms for the *same* traffic to avoid
   dealing with inter-group issues should not be an option.

-----
Caitlin Bestler
[email-masked] - http://www.asomi.com/CaitlinBestlerResume.pdf