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
_______________________________________________
use-revolution mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/use-revolution
