Re: my 2p worth
> 1.It would be interesting to know how many independentAlso, it would be very interesting (but hard to determine!) how much
> TCP implementations exist, and the rough proportions in
> which they are represented.
traffic each implementation contributes. This would let you gauge to
what degree a widespread PC implementation actually influences Internet
One idea floating around is having as one of the group's products a Web
page that would have this sort of info. Something along the lines of
which Jamshid Mahdavi et al put together. There are IETF issues regarding
a WG providing such a page which Allison & Allyn are looking into. We
should have something more concrete to say about this at the BOF.
> 2. It used to be the case that there were bugs in common implementationsDefinitely! This is one of the central goals of the WG as I see it.
> that you had to workaround ...
> it would be enormously useful to have these listed.
> 3. Most of the bugs mentioned are protocol issues or end-to-endThis also strikes me as within scope, though with the line drawn at
> performance issues on a single connection. Is it within scope to
> mention scalability issues, e.g. supporting large numbers of
> connections in TIME-WAIT?
the point where things cross into the research frontier. So, for example,
the issues raised in Joe Touch's draft RFC are good things to discuss;
but for some of them their resolution (e.g., how to share cwnd across
multiple connections) is research and needs to be dealt with in another
forum. It seems an important benefit of the WG is to highlight where
the research frontier is, too, so implementors can gauge where different
> 4. Are there bugs that crop up persistently in independent TCPLikewise, this strikes me as a mainstream goal for the proposed WG.
> implementations? e.g. mishandling of queued data for transmission
> when a close is issued? These would point to the most difficult
> 5. Should we separate buggy implementations of algorithms andDefinitely, if by algorithm you mean what's specified in an RFC. We need
> inappropriate (or debatable) algorithms?
to consider whether some of the RFC's need clarification or expansion, but
this is a considerably more significant step than cataloging implementation
- der Mouse <mouse@...> writes:
>I don't think there _is_ any "correctly". TCP does not have OOB. WhatI think the issue probably has more to do with interpreting what the urgent
>it has is an urgent pointer. Some grad student who must have been
>either on drugs or on a minimal understanding of TCP thought it would
>be useful to take the byte the urgent pointer points to and treat it as
>a byte in an out-of-band channel.
pointer means. If I remember correctly, 793 was ambiguous (it said two
different things in two different places) and BSD picked the "wrong" one
(having just re-read it, I probably would have too). If you follow 1122, then
you disagree with BSD by one byte, which is a real pain. I don't know why the
authors of 1122 didn't just admit defeat and codify the BSD practice ;->.