Subject: [tana] [Fwd: Re: [p2pi] TANA proposed charter]

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 23 Oct 2008 15:33:06 +0100

Nicholas Weaver wrote:
> 
> On Oct 23, 2008, at 6:53 AM, Gorry Fairhurst wrote:
>>>>
>>> It would be nice to add something about the fact that TCP strongly
>>> favours long-running flows over shorter flows and that this further
>>> exacerbates the problems of capacity sharing. Not sure if this should go
>>> here or in the first work item?
>>
>> I see what you are saying, but I am not sure this is the topic for 
>> this proposed WG. If we are working on LBE techniques, then I'd expect 
>> the new methods to be less aggressive that bulk TCP, which seems to be 
>> less than short-flows handling intense bursts of activity. Have I 
>> missed something?
> 
> This is the motivation for a scavenger-class from the ISP's viewpoint.
> 
> Currently, bulk-data P2P constists of many, long-lived TCP flows, and 
> thus causes problems when you have shared connections.
> 
> I'm not sure if its needed in the charter however.
> 

Sorry, my point here was only related to the specific issue of whether
we needed to call-out the case of lots of short flows...

Gorry
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

From: <[email-masked]>
Date: Thu, 23 Oct 2008 16:37:47 +0100

My main point was just to highlight a related issue. Clearly it would be
hoped that any LBE CC would be less aggressive and hence you should lose
the unfair advantage that longevity of your flow gives you. However,
when I think more about it I agree that this doesn't need to be
explicitly stated in the charter.

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 also gives a hint as to an additional piece of mechanism that might
be usefully explored by this (or a related) WG - allowing users to
associate a "complete by" time with any downloads and use this to
determine how aggressive you need to be.

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Gorry Fairhurst
> Sent: 23 October 2008 15:33
> To: [email-masked]
> Subject: [tana] [Fwd: Re: [p2pi] TANA proposed charter]
> 
> 
> 
> Nicholas Weaver wrote:
> >

---

From: Laird Popkin <[email-masked]>
Date: Thu, 23 Oct 2008 11:53:52 -0400 (EDT)

I think that the issue of application motivation for implementing "less than best effort" is the greatest challenge to the adoption of whatever we come up with, but it's not an entirely technical issue, so I don't know how much we can address it within a WG.

That being said, I'd hope that in practice there is a clear benefit to applications for being "polite" and using this protocol. For example, I'd hope to see ISPs give some benefit to traffic that is "less than best effort", such as not counting such traffic against users' capacity limits (or charges).

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "toby moncaster" <[email-masked]>
To: [email-masked], [email-masked]
Sent: Thursday, October 23, 2008 11:37:47 AM (GMT-0500) America/New_York
Subject: Re: [tana] [Fwd: Re:  [p2pi]  TANA proposed charter]

Toby

Of

---

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

> 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
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

From: Bryan Ford <[email-masked]>
Date: Thu, 23 Oct 2008 18:23:58 +0200

On Oct 23, 2008, at 5:53 PM, Laird Popkin wrote:
> I think that the issue of application motivation for implementing  
> "less than best effort" is the greatest challenge to the adoption of  
> whatever we come up with, but it's not an entirely technical issue,  
> so I don't know how much we can address it within a WG.
>
> That being said, I'd hope that in practice there is a clear benefit  
> to applications for being "polite" and using this protocol. For  
> example, I'd hope to see ISPs give some benefit to traffic that is  
> "less than best effort", such as not counting such traffic against  
> users' capacity limits (or charges).

Actually, an excellent paper just appeared in this year's HotNets-VII  
by Nikolaos Laoutaris and Pablo Rodriguez that describes at least one  
promising incentive model that could help drive user deployment and  
ISP support for a background congestion control scheme for bulk data:

	Good Things Come to Those Who (Can) Wait,
	or how to hand le Delay Tolerant traﬃc and make peace on the Internet
	http://conferences.sigcomm.org/hotnets/2008/papers/20.pdf

The short version of the proposal is that ISPs rate-control their user  
in such a way that if the user voluntarily throttles their use during  
peak load periods, the user gets a lot more bandwidth than their  
normal "default allocation" during off-peak periods, essentially  
incentivizing users to shift their bulk transfers to off-peak times.   
A background congestion control scheme whose use ISPs could detect and  
monitor could enable implementing such an incentive scheme in a  
completely dynamic and automatic fashion: i.e., background traffic  
would back off during "actual" periods of congestion (and get rewarded  
with additional bandwidth at other times for doing so), rather than  
just backing off during a fixed "peak" daily time period as the paper  
suggests.

I know analogous incentive schemes have been proposed by others; I  
think the WG should definitely at least catalog and analyze some of  
them, and possibly make recommendations on their deployment.

Cheers,
Bryan

---

From: Janardhan Iyengar <[email-masked]>
Date: Thu, 23 Oct 2008 12:50:35 -0400

Hi Toby,

> determine how aggressive you need to be.

This is interesting to me: if I start a download at night, I'm fine with the download taking all night if it needs to. Of course, you expect that most users would select the "ASAP" option, but there's room for play here, and it could be a fairly useful input to help determine how aggressive a transport needs to be.

(I just saw Bryan's email come in about the HotNets paper I was about to mention here!)

The flip side (also to your earlier point): TCP does not assume anything about available bandwidth beyond RTT scales, but a mechanism like the one you are suggesting will probably need to make some assumptions about variability in available bandwidth predictions way beyond RTT scales.

- jana

-- 
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar

---

From: Janardhan Iyengar <[email-masked]>
Date: Thu, 23 Oct 2008 12:29:06 -0400

Hi Toby,

- jana