Broadband Optimizer for Revolution?

[Alex Tweedly]

Dar Scott wrote:

> slow start undoubtedly is part of TCP proper;
>
> Huh?  It is not in rfc 793.
>
That means that it was not part of the original TCP standard.

I guess it's the usage of that word "proper" :-)

1122 is an IETF standard, and so anything it says is a requirement for 
host TCP implementations is definitely included in "proper" - this 
includes the slow start algorithm (see below)

2100 and later 2581 were proposed standards - they were never ratified 
to full standard, but are very widely implemented.


>>> 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.

If I said something that implied that the transmit buffer size had to be 
the same as the window, then it was just a failure to express myself 
clearly - sorry.
A sender's transmit buffer can be as small as he wishes (actually, I 
think there may be a requirement that it be at least one MSS - it would 
certainly be odd for it to be smaller than that).

>
> 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.

rfc1122 is a full IETF standard, and so the requirements it places on 
host implementations of TCP are part or the official definition of TCP 
(even though they weren't in the *original* TCP standard). Note in 
particular this section

         4.2.2.15  Retransmission Timeout: RFC-793 Section 3.7, page 41

            The algorithm suggested in RFC-793 for calculating the
            retransmission timeout is now known to be inadequate; see
            Section 4.2.3.1 below.

            Recent work by Jacobson [TCP:7] on Internet congestion and
            TCP retransmission stability has produced a transmission
            algorithm combining "slow start" with "congestion
            avoidance".  A TCP MUST implement this algorithm.


(note there was an exception made in the rfc index - 1122 (Host 
requirements) and 1812 (Router requirements) modified so many earlier 
RFCs that it was decided to omit the usual requirement that all RFCs 
modified by them be marked as such in the index).

rfc2001 isn't part of the official spec of TCP, since it never made it 
past proposed standard.

> Thanks for the pointers to rfc 1122 and rfc 2001.

If you ever get  involved in (off-LAN) high performance TCP, you might 
find 3390 interesting as well. Also not a standard, but has lots of good 
analysis and experience behind it.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.3.0 - Release Date: 30/05/2005