Re: [p2pi] [tsv-area] TANA proposed charter

[Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>]

Overall, I like the charter.


The one problem I have, however, is not technical but the economic  
model.

One can do a fairly decent (not great, but OK) approximation today by  
using a delay-based (eg, TCP-vegas) congestion control, as its  
designed to minimize queues and tends to get outcompeted by TCP reno  
(the two big-desired).

Especially since intuition suggests that you could do this "single- 
ended", have the TCP stack on ONE side do delay-based estimation in  
both directions, and request window resizing to control the other  
side's sending rate.

Yet why would a bulk-data content provider want to USE it?


If the business model is "Video or other bulk data NOW", you don't  
want it friendlier than TCP, you only want to make sure you don't kill  
the queues on a customer's access device (if P2P).  Thus the goal is  
ONLY to minimize queues, because being friendlier than TCP otherwise  
might get your data squeezed out in the rest of the network.

If anything, you might want to be more HOSTILE, because you have a  
minimum aggregate data rate (averaged out over say 10-30 seconds of  
buffer) you need to keep a realtime display going.


If the business model is "Video or other bulk data OVERNIGHT", then  
you are competing with the US Postal Service for legal content, which  
is pretty darn cheap for bandwidth.


I'd really like a "Less Than Best Effort" data class/congestion  
control that does not populate queues and yields completely (on the  
order of a couple of RTTs) to conventional TCP.  But I really wonder  
who'd use it?


On Oct 21, 2008, at 8:06 AM, Bruce Davie wrote:

> I'll start by saying that I support the WG and think the new charter  
> is pretty good. I have a few suggestions for small changes.
>
> > Applications that transmit large amounts of data for a long
> > time with congestion-limited TCP, but without ECN fill the
> > buffer at the head of the bottleneck link.
> Replace ECN with Active Queue Management (AQM)

I'd actually say "ECN or Active Queue Management"

> > In the best case,
> > with an ideally sized buffer of one RTT, the delay doubles. In
> > some cases, the extra delay may be much larger.
>
> Since there isn't complete agreement on the ideal size of a buffer,  
> just say:
>
> "If the buffer size is one RTT, the delay doubles...."

Especially since the bottleneck devices in question are sometimes  
obscenely overbuffered.

> > (1) An experimental congestion control algorithm for
> > less-than-best-effort "background" transmissions, i.e., an
> > algorithm that attempts to scavenge otherwise idle bandwidth
> > for its transmissions in a way that minimizes interference
> > with regular best-effort traffic.
> >
> > Desired features of such an algorithm are:
> > * saturate the bottleneck,
> > * eliminate long standing queues and thus keep delay low when
> > no other traffic is present,
> > * quickly yield to regular best-effort traffic that uses
> > standard TCP congestion control,
>
> perhaps it would be more precise to say:
> "quickly yield to traffic sharing the same bottleneck queue that  
> uses standard TCP congestion control"

One question is "How MUCH yielding".  Should the nicer-than-TCP flow  
go to 0?  Or should there be some equilibrium value (eg, with 2 flows,  
one TCP, one friendly-bulk-data, should it be something like 75/25?)


_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi