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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Murali Bashyam wrote:
...
> 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?

It's implied by the conditional. I.e., if the receiving TCP stops
sending ACKs, the sending TCP can drop the connection.

As to the sending side, there's the ABORT call in 793 - which we
discussed on this list before. The point is that _TCP_ can't decide to
stop the connection because of the TCP state of the other end, the local
TCP state, or behavior on the wire. Nothing in 793 says that the OS
can't kill the connection - any connection - at any time.

>> 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.

Please describe anywhere in 1122 or 793 where memory management is
described.

As I've noted before, this isn't a protocol violation - it's a failure
of an OS to support arbitrary numbers of instances of a protocol.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjlx4cACgkQE5f5cImnZrvVIACgy317tNIROKQF8JMq1b3osIEc
4bkAoNG6gnVh3RQ3ZXGe0nStL3ot2QVY
=plLF
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm