Re: Last Word on An IPS Transport Protocol?

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

Y P:

It is NOT within the scope of this WG to change ANY Congestion
Control parameters of TCP. The working group COULD spend a year
or so and define its OWN protocol.. HOWEVER it WOULD HAVE TO HAVE
congestion control compliant to RFC 2581! This means you do not get
anything even close to your proposal.

The bottom line is changing the congestion control is NOT allowed..IMHO

R

Y P Cheng wrote:
> 
> > Sorry, that doesn't achieve the goal of complying with RFC 2581.  If the
> > "Delay Constant" is set incorrectly for the network, the result is
> > disastrous - the whole point of slow start is to set and adjust parameters
> > like the "Delay Constant" automatically in a fashion independent of
> network
> > conditions.   Also see the discussion in RFC 2581 about initial window
> size.
> 
> If slow start is needed to avoid disaster on the network, I don't have any
> problem with a slow start.  However, the cost on performance -- taking 1.6
> sec to transfer one MB of data using slow start -- must be considered.  When
> the MTU is small, 512 instead of 2K, the cost is even higher.  How long does
> it take to move one gigabytes of data with iSCSI on a network with 50 msec
> round-trip delay?
> 
> > In other words, change the TCP protocol to make it go faster for your
> > traffic without changing the TCP header format.  Not only is this
> > not a good idea, but the approved WG charter specifically PROHIBITS the
> > WG from working on this, unless the argument can be made that the
> > changes are required for storage traffic.  I believe the current WG
> consensus
> > is that TCP congestion control is good enough for storage traffic,
> > and hence would like to put an end to this thread.
> 
> Dave, I think you have missed a very important part of my proposal.  We must
> stream the data transfer with DMA assist to overcome the performance problem
> of storage traffic on a network with long delay.  Changing or not the TCP
> header is not my point at all.  The proposed protocol does not change the
> TCP protocol either if the sequence size is set to one, i.e. the segment
> size.
> 
> 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.
> 
> If the WG does not see this point and believes otherwise, I will submit to
> the wish of this WG.  But I do believe the current discussion has totally
> missed the effect of the long latency network delay.
> 
> Y.P. Cheng, CTO, ConnectCom Solutions Corp.

-- 
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222 (cell) 815-477-2127 (work)