The persist document can be summed up in one sentence: Connections that are in
persist (zero window probe) are no different than any other connection in
established state.
When RFC 1122 was written, there existed TCP implementations that were dropping
connections in persist state, treating connections that did not move forward
the same as connections that weren't getting any ACKs. RFC 1122 said, no, as
long as you are getting ACK responses, the connection is still valid, and TCP
shouldn't be timing out the connection.
Some TCP implementors read that as meaning that connections in persist state
had to be handled specially, and swung the pendulum to the other extreme, and
wouldn't drop connections in persist state even when under the exact same
circumstances they would drop other connections in established state.
This ID is trying to get the pendulum back to the center. From the perspective
of the TCP protocol, as long as ACKs are being received to probes while in
persist state, the connection is valid. Other things outside the TCP protocol,
such as applications or the OS, can decide to terminate any TCP connection for
any reason. An application exits. The OS is running out of resources and
decides to abort TCP connections. Someone shuts down the computer. There are
lots of things outside of the TCP protocol that can cause TCP connections to be
aborted.
This ID is not changing anything in the TCP protocol. It is only correcting
how some implementors had mis-interpreted RFC 1122, and this mis-interpretation
is by no means universal. The WG consensus was that this makes it
Informational.
-David Borman
On Jun 5, 2011, at 10:39 PM, Brian E Carpenter wrote:
> Wes,
>
>> This document contains no protocol and alters no protocol.
>
> True, but it makes a strong statement about what implementations
> must do. I had a quick look, and most implementation guidelines
> are Informational, although one or two (e.g. RFC 5625) are BCP.
>
> It would be a lot clearer to a new reader if the title indicated
> that it's an implementation guideline - I certainly started reading
> on the assumption that it was a protocol update, which as you say,
> it isn't.
>
> I'm sure the IESG will come back with a proposed resolution.
>
> Regards
> Brian
>
> On 2011-06-06 15:20, Wesley Eddy wrote:
>> On 6/5/2011 8:18 PM, Anantha Ramaiah (ananth) wrote:
>>> Michael,
>>> I am sometimes confused with the thinking of *some* TCPM work group
>>> members esp., for such simple drafts(harmless drafts). Now, what if it
>>> is a standards track document, would it be harmful to the internet? Or
>>> if it is informational it would be considered less harmful ? I simply
>>> don't get the point.
>>> At this point I wanted to mention that we have really removed a lot
>>> of contents like API guidance for implemenmters etc., from this draft.
>>> The draft as it stands now is purely a clarification of RFC 1122's
>>> persist behavior which was the original intent for which there was a
>>> reasonable consensus. The WG members need to explain clearly why they
>>> are nervous about making it a standards track, FWIW, lets take the
>>> urgent pointer clarification RFC which was recently issued (RFC 6093),
>>> that is a standards track document. It simply clarifies the intentions
>>> and usage of urgent pointer, and it is harmless. This document is very
>>> similar to that, IMO.
>>>
>>
>>
>> This document contains no protocol and alters no protocol.
>>
>> I don't agree with attempting any comparison with RFC 6093. That RFC
>> changed the specification of the urgent pointer, whereas this
>> draft does not change the TCP specification one iota.
>>
>> It's hard to see how Standards Track is appropriate for this draft.
>>
>> I agree with Michael that "MUST" versus "must" should make little
>> difference to a reader; they'll get the point.
>>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
