Broadband Optimizer for Revolution?

[Dar Scott]

On Jun 1, 2005, at 4:06 AM, Alex Tweedly wrote:

> "transmit window" came into common usage sometime around the early 90s 
> - to refer to the sender's view of the congestion window. An 
> application trying to figure out if it is near to congestion (and 
> perhaps vary the info it is sending accordingly) should probably use 
> this rather than the size of the congestion window (though of course, 
> since it's TCP not everyone agree on that).

We may be using "congestion window" differently.  It seems you are 
talking about the TCP window.  I was referring to a  self-limitation by 
the sender.

> slow start (and congestion avoidance - independent ideas but a merged 
> implementation)  was first described and implemented by Van in 1988, 
> and then in  rfc 1122 (Host requirements) congestion avoidance became 
> a required feature for TCP implementations. It became a formal part of 
> the rfc system in rfc2001 - but that was long after it had become 
> common.

I am aware of Van Jacobson's work, but both rfc 1122 and rfc 2001 are 
blind spots.


> slow start undoubtedly is part of TCP proper;

Huh?  It is not in rfc 793.

> the use of the term "transmit window" is not defined by any rfc (afaik 
> - didn't search to check), but is ubiquitous in the IETF community. I 
> think the term transmit window is worthwhile since it expresses the 
> fact that the congestion window being used is that seen by the sender, 
> whereas the congestion window can be manipulated by both sender and 
> receiver.

I've been using "congestion window" in the Van Jacobson sense, not for 
the TCP window.

>> The "send window" is really just the senders view of the standard TCP 
>> window and should not refer to self-limitations of the sender.
>
>> Even so, thanks for this info.
>>
>> I think you're saying that the "congestion window" used by some 
>> implementations is limited by both the TCP window (called "receive 
>> window" by some) and some configuration called the "transmit window".

> Not quite - see the terminology in rfc2001 (slightly different from 
> what 793 had used).
> The advertised window is what the receiver advertised.

This is the standard TCP window.  I see that is what rfc 2001 calls it.

> The congestion window is the sender's modification of that - varied 
> both by sender's configuration and more importantly by congestion that 
> has occurred.

This should not be greater than the standard TCP window.  Other than 
that, that's what I just said.

I looked at rfc 2001 and that is consistent with the usage that I'm 
familiar with for "congestion window"; it is a TCP implementation 
parameter for the sender, not the TCP window.

>> This imposes a minimum on the transmit buffer size, and it seems you 
>> are saying that the practice is also to make this the maximum on the 
>> transmit buffer.  Did I get that right?
>>
> No, I don't think it imposes a minimum on the transmit size; why would 
> it ?

All bytes not acked have to be saved for retransmission.  They must 
remain in the buffer.  The transmit buffer must be large enough to hold 
everything.

Now to use this same size as a maximum as you suggested is an undue 
constraint on the client to me.  That might force the application to 
buffer.


I have implemented TCP on a LAN for control systems before and without 
slow start, but in that case slow start should be avoided for 
performance reasons.  I noticed that rfc 2001 did mention that is OK 
for a LAN, so I accidently complied with that.

Remember, rfc 1122 and rfc 2001 are not TCP/IP.  Those are just 
implementation constraints and are more recent.

They do not apply to cases when messages from A to B must get there as 
fast as possible and must maintain a realtime schedule.

Thanks for the pointers to rfc 1122 and rfc 2001.

Dar

-- 
**********************************************
     DSC (Dar Scott Consulting & Dar's Lab)
     http://www.swcp.com/dsc/
     Programming and software
**********************************************