On Friday, July 01, 2005 07:58:42 AM +1000 grenville armitage
<garmitage(_at_)swin(_dot_)edu(_dot_)au> wrote:
Brian E Carpenter wrote:
Hans Kruse wrote:
...
but otherwise I _cannot_ see how the _content_ of the option could
harm a device that does not want to deal with it.
If it interferes with congestion management elsewhere along the path, it
can potentially damage
every other packet stream. This is a *very* complex discussion of course.
I can see it interfering for two reasons. (a) The option codepoint clashes
with the codepoint used by another congestion management mechanism
(thereby
confusing routers handling packet streams using the same codepoint
differently),
or (b) IPv6 option handling is flawed in so far as an unknown option
turning
up in a packet stream can totally mess with 'congestion management
elsewhere
along the path'.
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?
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, 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.
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.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+(_at_)cmu(_dot_)edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf