RE: Last Word on An IPS Transport Protocol?

[Black_David@emc.com]

> My contention is the current TCP congestion control is NOT good enough and
> the ACK traffic on a network with long latency delay is BAD.  We must have
> streamed transfer on a network with long latency.  Therefore, defining the
> ACK of TCP is critical.  The TCP header format is not sacred to me.

It's time to put my WG co-chair hat on and play "bad cop" ...

There are experimental and production results indicating that TCP is
capable of saturating arbitrarily high bandwidth networks with arbitrarily
long delays.  Buffering proportional to the bandwidth-delay product is
a good idea, so this doesn't come for free.  Streaming transfer
can be achieved without playing these sort of ACK games - of course
if congestion is encountered, TCP backs off dramatically.

This WG does not have the license to fundamentally change TCP's
congestion control algorithm or to use a transport that does not implement
congestion control in a sufficiently TCP-like manner (RFC 2581 compliance
is sufficient); the co-chairs and ADs will reject any document that
tries to do either of these things.  Please don't consume list bandwidth
in further discussion of this.

Developing a new transport with sufficient congestion control is going to
take time.  If the WG were to go in this direction, at least a year should
be added to all of the completion milestones in the charter.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
--------------------------------------------------