Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
> Joe Touch
> Sent: Thursday, October 02, 2008 5:55 PM
> To: Murali Bashyam
> Cc: Anantha Ramaiah (ananth); tcpm@ietf.org; David Borman
> Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Murali Bashyam wrote:
> ...
> >> I have reservations about moving forward with this draft as a wg
> >> document.  While the information is technically correct, it is
> overly
> >> specific to the point of possibly being misleading rather than
> >> clarifying.  An operating system may terminate a tcp connection at
> any
> >> time, not just when the connection is in the persist state.
> Further,
> >> I would actually argue that terminating a connection *because* it's
> in
> >> the persist state is a bad idea and should be discouraged.  (The
> >> reason for termination should be for its use of resources, not TCP's
> >> state.)
> >
> > No implementation today (the well-known ones BSD, Windows and Linux)
> > terminates the TCP connection in that persist state as long as ACKs
> are
> > being reliably received from the peer.
>
> No OS I'm aware of cleans much of anything up when it runs out of
> space.
> They tend to just run out of space and silently hang or thrash
> incessently.
>
> The point is that an OS that wants to do this can. That's an OS
> implementation recommendation that I support - the question is whether
> such OS implementation issues are useful as RFCs.
>
> > Those three implementations are
> > not doing what you are saying they should be doing, and if it's
> crystal
> > clear from the standard that they should be doing so, why aren't
> they?
>
> The standard already says, IMO, that they MAY do this. Not that they
> MUST. The standard says nothing about what to do when you run out of
> resources to run the connections you're currently supporting - it says
> nothing about what to do when new connections arrive in that state
> either. Memory management is the OS's job, not the protocol's.

Which standard are u referring to? I'm quoting from RFC 1122, page 91
the section on probing zero windows :

"As long as the receiving TCP continues to send acknowledgments in response to the
Probe segments, the sending TCP MUST allow the connection to stay open."

Can you point me to the word "MAY" in that sentence that you are referring to?
The important thing here is to clarify that sentence and the sender's behaviour and prevent what appears to be a conflict between memory management and protocol violation.

>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkjlbVkACgkQE5f5cImnZrs/fQCfYqFOdyjmg9aVMxyuMjY2eDZd
> svkAnjvVH/Rq5E93BOsp5A/ZzKv4LBjL
> =p3nQ
> -----END PGP SIGNATURE-----
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm