Broadband Optimizer for Revolution?

[Alex Tweedly]

Dar Scott wrote:

>
> On Jun 1, 2005, at 9:23 AM, Alex Tweedly wrote:
>
>> 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
>
> ...
>
>>         A TCP MUST implement this algorithm.
>
>
> That is an interesting interpretation.
>
Well, it is the IETF's interpretation (the chair of the IETF & IESG 
worked for me for 4 years:-)

> I read that last sentence from RFC 1122 as meaning "A TCP must 
> implement this algorithm to comply with RFC 1122."  A TCP is TCP if it 
> complies with RFC 793.
>
A TCP is 793-compliant if it complies with 793. It will always be 793 
compliant - but the definition of "TCP" can, and did. change over time.

> It seems you are saying that compliance with one IETF standard 
> requires compliance with all.
>
No - compliance with any standard only requires compliance with it and 
any others referenced from it.
But compliance with "current standards" or with named standards (e.g. 
UDP, TCP)  changes over time.

> To me that contradicts the notion of all RFCs being valid standards 
> but some (for compliance) over-shadow others.  One RFC cannot change 
> another.  Any implementation that complies with an RFC will always 
> comply with it.
>
One RFC can obsolete another. One RFC can update another.
See the intro to http://www.ietf.org/iesg/1rfc_index.txt

> Even so, I need to get out of the dark ages.  I was aware of Van 
> Jacobson, Korn & Partridge, and Nagle, but was blind to thinking of 
> these as standards.
>
> (I had been interested in SCTP, and still am somewhat, but this has 
> slow start built-in.  Just as PCI leaped to PCI Express to properly 
> handle congestion, I would have hoped SCTP would do the same for IP 
> but it uses the some methods as many TCP implementations.

Yes, I had many hopes for SCTP (two of the authors worked in my group 
for a while just after the rfc came out). It had little choice but to 
use much of the same congestion control as TCP - the IETF is 
supersensitive to the dangers of congestive collapse, and politically it 
would not have progressed without taking that line. Large initial window 
mods would solve these problems if used in controlled circumstances; 
over the general Internet, I think there is still need for conservative 
congestion control.
(Note you can use RSVP or other QOS reservation/negotiation scheme to 
ensure that going slightly outside the TCP standard is relatively safe 
even over multi-hop networks - though you'll struggle to get a 
RSVP-enabled ISP unless you have a ton of money to spend ...)

>   Can you imagine communicating with the Mars Rover with slow start TCP?)

Not easily :-)
But I can imagine using TCP incorporating rfc3390 (or further 
modifications of that); and if I was building the comms kit for Mars, 
I'd be quite happy to ignore certain parts of the standards specs, 
knowing my circumstances were very different from those needed in the 
general Internet.

(though if I were doing inter-planetary comms, I wouldn't use TCP - I'd 
use parallel unidirectional streams, probably UDP, with FEC and transmit 
full-blast without congestion or flow control :-)

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