Jeffrey Hutzelman wrote:
On Friday, July 01, 2005 07:58:42 AM +1000 grenville armitage
<garmitage(_at_)swin(_dot_)edu(_dot_)au> wrote:
[..]
Scenario (a) would seem to be solved by assigned a non-conflicting option
codepoint and then hoping the competing protocol dies of irrelevance.
Scenario (b) suggests we have bigger problems. I'm honestly hoping it
isn't
scenario (b), and that there's an scenario (c) I'm just not seeing.
Have you read the spec in question?
Actually (and conciously), no. I was tempted to do so, but my position
isn't about the protocol which would be indirectly indicated by the
requested codepoint. My position is about the assignment of a codepoint,
itself merely a neutral bit pattern in packets passed from one end point
to another. A bit pattern that, if known, could be used by operators to
filter or pass packets implementing the protocol to which some object.
A bit pattern which, if unknown, cannot be used for said filtering or passing.
I'm not trying to remain ignorant of the protocol in order to be a nuisance,
more to remain clear-headed (well, IMHO, and I concede this certainly makes me
less sesitive to the basis for the IESG's broader misgivings.)
The issue is not that the presence of an unknown option interferes with
congestion control. The problem is that when the endpoints _do_
implement the option,
Well, more precisely, when the endpoints "_do_ implement the protocol that
would be _represented_ by the requested option" ....
they can sometimes decide to disregard TCP
congestion control procedures such as slow-start, which while
implemented on an end-to-end basis nonetheless affect congestion control
on all intervening segments.
I'm not at all unsympathetic to the negative consequences of a modified
TCP-like behaviour. (On the contrary, in fact.)
Now, it's possible that, in the circumstances in which this spec allows
endpoints to punt on slow-start, it is actually safe to do so without
risking causing problems for the rest of the network. But I haven't
read the document in enough detail to know that, and the potential for
problems if it is not is quite large. I'd be much happier if any
proposal along those lines were reviewed by the IETF (particularly,
experts in IPV6, QOS, TCP, congestion control, etc) before being
unleashed on the Internet.
Indeed, and I too agree that there's probably a substantial amount of
useful work to be done refining (or rejecting) the algorithm underlying
the protocol changes to which the requested codepoint would have pointed.
My only concern is that we're using codepoint assignment denial as a means
of protecting the Internet from poor, TCP-unfriendly end2end algorithms. And
that just doesn't seem reasonable. (As someone else observed, two or
more consenting endpoints don't need new codepoints to implement an e2e
congestion control behaviour that's detrimental to current TCP. They
might even hide their malicious behaviour inside UDP packets!)
So, I'm not necessarily disagreeing with the IESG's summation that Dr Robert's
proposed protocol could be detrimental. But it would seem to have been more
preferable to assign a codepoint with a public notation 'packets carrying
this option represent flows using a non-IETF approved congestion control
algorithm' (or some such text).
There should have been a famous person who said 'Keep your friends close,
and enemies well documented' ;)
cheers,
gja
--
Associate Professor Grenville Armitage
Director, Centre for Advanced Internet Architectures
http://caia.swin.edu.au
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf