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

[Joe Touch <[e-mail]>]

Anantha Ramaiah (ananth) wrote:
> John:
>  
>>> A) Do we agree that it is a problem ? [the title of the thread]
>>>
>>>    Most people seem to agree on this.
>> I would like to step back even further, and work on the 
>> definition of "it" -- the problem we want to solve.  In my 
>> mail on Nov 14 (which did not elicit a response), I tried to 
>> make the case that the issues framed in the draft are in fact 
>> only a special case of a more general problem.
> 
> Sorry I haven't read that. Will do.
> 
>> I do not believe the indefinite nature of TCP's persist state 
>> is intrinsically something we need to fix -- in fact, it is 
>> clearly an important and useful feature of TCP.  It might not 
>> be terrible for a TCP implementation to provide a switch for 
>> an implicit ABORT after a long persist timeout.  However, in 
>> my opinion this is not the best solution, or even a solution 
>> at all to the more general problem.
> 
> Pl see the question I posed to in response to Ted's email. Having an
> implicit ABORT or having a socket option is very useful thing. It is the
> "basic infrastructure" needed in TCP and TCP API layer (like sockets).
> Now, if I follow RFC 1122 language, it seems to preclude me from doing
> the above. Doing such a thing is an RFC voliation? Does it need some
> clarification?

RFC1122 allows you to abort a connection explicitly. It allows you to
have an user application timer to abort a connection explicitly. It
allows you to have an OS timer that aborts a connection explicitly. To
TCP, the OS and/or user application are not distinguishable.

Now if you "set a local timer that initiates an explicit call" and want
to call that "implicit", that's fine. It's still explicit ultimately
(i.e., a real abort call is issued), and still supported by RFC793 and
RFC1122.

Joe

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