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
