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

[Joe Touch <[e-mail]>]

Anantha Ramaiah (ananth) wrote:
>  
>>> IMO, the informational RFC which is what is being attempted, should 
>>> clarify this. The whole point of my question was to 
>> understand whether 
>>> terminating a connection stuck in persist state is 
>> considered RFC 1122 
>>> compliant. It appears from responses so far, it is compliant.
>> 1122 allows terminating a connection at any time for the 
>> reason that the application has instructed so. 1122 makes no 
>> distinction about the progress of a connection affecting that control.
> 
> Implicit above OR an example scenario of the above statement is :, "1122
> allows terminating connection stuck in persist state". Now how and where
> it is done is beyond the scope of any standard RFC (including 1122) and
> there are several ways to implement the rules.

Explicit above is that the application must initiate ABORTs - either by
control of a timer or directly.

1122 prohibits TCP from, absent explicit indication from an application,
deciding to abort a connection based on the lack of progress.

> Now "progress of a connection and taking some action" all fall under
> implementation section, aborting of the connection is like a knob, you
> turn it when you determine that you need it.

1122 specifically prohibits TCP from deciding to abort a connection
because the offered window isn't open (sec 4.2.2.17). The difference of
which entity controls the abort - the application or TCP - is important
to whether 1122 prohibits it or permits it.

Timers inside TCP are equivalent to user action outside TCP, but events
inside TCP that depend on state that TCP can determine but applications
cannot are not equivalent in that regard.

I.e., there is latitude in implementation, but it is not full latitude.

Joe

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