Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

[John Heffner <[e-mail]>]

Joe Touch wrote:
> 
> Mark Allman wrote:
>> [hat off]
>>
>> I am not sure where in this thread to weigh in, so I am just replying to
>> the last thing in my inbox.
>>
>> I think a couple of things:
> ...
>>   + I disagree with the reading of RFCs 793 & 1122 that a connection
>>     that is doing zero window probing must remain up forever as long as
>>     the probes are being ACKed.  I think in 'times of trouble' a TCP is
>>     well within its rights to terminate a connection and I do not think
>>     that should in any way be viewed as non-compliant.  TCP connections
>>     are local resources and therefore should remain under local
>>     control.  If something locally determines that resources are low and
>>     connection should be terminated for whatever reason then I don't see
>>     how that is any of anyone else's business.
> 
> The point of 1122 is that TCP isn't the one to decide this, AND that
> connections with zero windows with ACKs aren't to be singled out.
> Applications can kill connections, and certainly the OS can just shut
> down. However, an OS that decides to kill connections because it runs
> out of resources is noncompliant.
> 
> That OS is required to reserve per-connection resources when connections
> are created. It can halt new connections.
> 
> It *CANNOT* kill existing connections to make up for poor resource
> management and call itself compliant with the current language in 1122.


I really have to disagree here; I do not believe an OS terminating a 
connection violates the spirit of 1122.  Things like processes, address 
spaces, etc., are well outside the TCP standard's realm.  In my view, an 
operating system (the kernel, a helper daemon, or other) can be 
considered a "User" of TCP (in RFC793 terminology), and be fully 
compliant when making API calls (including ABORT) to connections that 
might be "owned" by some other process.

One question: is the deleteTCB(12) state of RFC4022 in conflict with 
RFC1122/RFC793?

   -John



_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm