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

----- Original Message -----
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Joe Touch" <touch@ISI.EDU>
Cc: <tcpm@ietf.org>
Sent: Thursday, November 22, 2007 12:42 AM
Subject: RE: Summary of responses so far and proposal moving forward [WasRe:
[tcpm] Is this a problem?]

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

Ok, I am not sure if the rest of the WG feels the same way you do. If
what you say is true, implicit abort isn't an issue, so in theory I CAN
have a timer inside my embedded system (it can running anywhere inhe
system), and it can abort the connection through some interface.
Actually no-one would even notice this behaviour since one really can't
determine from "outside"" whether the connection was aborted implicitly
or explicitly.

So I gather that there is no need to have a standards change, since you
seem to say that RFC allows you to abort a connection which everyone is
aware of. But it is the same RFC that says you MUST persist a connection
<>
Anantha

No, that is not what the RFC says; as Joe has pointed out, the RFC says what TCP
MUST do (and that changing it is a big deal).  Note the title of the RFC -
'Requirements for Internet Hosts - Communication Layers' - and that there is a
companion RFC1123, dated now because applications have moved on, but you will
not find in the latter prohibitions on applications terminating connections.
RFC1122 defines what is available for applications to use, what applications can
rely on; it does not define what those applications do with that functionality.

So; is there a problem?  Yes, but it could be regarded as an implementation
problem rather than a protocol one, and certainly not worth a change in TCP.
Worth an RFC? may be.

Tom Petch
<>

indefinetly as long as you receive ACKS, so you are now providing an
external override for this MUST behaviour.

Hmm... I would also like to get others comment on this...

-Anantha
>
> Joe
>
>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm