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

From: Murali Bashyam <[email-masked]>
Date: Thu, 20 Nov 2008 23:33:35 -0800

Wes/David

What are the next steps for this document to be considered a  WG item? Can we get some closure on this draft?

Thx,
Murali

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Murali Bashyam
> Sent: Saturday, October 04, 2008 9:49 PM
> To: David Borman; Murali Bashyam
> Cc: Anantha Ramaiah (ananth); [email-masked]; Ted Faber
> Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
>
>
>
> > -----Original Message-----
> > From: David Borman [mailto:[email-masked]]
> > Sent: Friday, October 03, 2008 2:05 PM
> > To: Murali Bashyam
> > Cc: Ted Faber; [email-masked]; Anantha Ramaiah (ananth); Murali
> Bashyam
> > Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
> >
> >
> > On Oct 3, 2008, at 2:37 PM, Murali Bashyam wrote:
> > >
> > > My intent was that even where TCP implementations have a scheme for
> > > dropping connections in the event
> > > of resource exhaustion (such as the Linux one does), they have
> > > excluded connections in this state.
> > > The point i am trying to convey is that the 1122 portion has
> > > (mis)guided them in that direction.
> >
> > If this is true, it should be clarified.  1122 does not in any way
> say
> > that ABORT does not apply to connections in persist state (probing a
> > zero window).
> >
> > ...
> > >> In light of that I think that the sentence about "TCP itself
> SHOULD
> > >> not[sic] take any action..." is more confusing than the 1122
> > section.
> > >> It seems to imply that TCP might react differently to an abort
> than
> > >> the single paragraph in 793, and I don't think that's the case.
> > >
> > > What's meant here is that it's okay for the connection to get
> > > aborted in this state, whatever the mechanism for doing
> > > so maybe: TCP can abort the connection and inform the application,
> > > similar to the retransmit/persist timeout mechanisms
> > > already in place, or the application can choose to abort the
> > > connection based policy, or the OS can do so based
> > > on resource management criteria. We can re-word that sentence and
> > > paragraph to reflect this.
> >
> > Just to be clear: TCP DOES NOT ABORT THE CONNECTION!  The OS or the
> > application can choose to ABORT the connection, but TCP does not make
> > this decision.  TCP does have retransmit timers, and it is allowed to
> > terminate unresponsive connections, but it does not abort connections
> > just because they are in persist state for long periods of time.
> > Until you are running out of resources there is no good reason to
> > terminate connections in persist state, and when you are running out
> > of resources, it is the OS that is deciding whether or not to ABORT
> > any TCP connections.
>
> I agree that the retransmit/persist timeout analogy doesn't apply to
> this situation.
> It is ONLY the OS or resource manager or the application that can
> terminate the connection
> In this state.
>
> >
> >
> > >> Now, a strictly defined abort command seems to somewhat contradict
> > my
> > >> earlier comments about allowing implementers some freedom.  This
> is
> > a
> > >> spot where the standards body has required a specific tool to be
> > >> available to applications (and OSes and resource managers): there
> > >> must
> > >> be a way to annihilate a TCP connection from outside without
> regard
> > >> to
> > >> its state or anything else.  The standard is silent about how the
> > >> command is used; that's the flexibility here.
> > >
> > > The abort semantics as specified by 793 are clear, they are not
> > > specific to a particular state, it's the opinion
> > > of the authors that 1122 excludes it from being applied in this
> > state.
> >
> > Yes, that is an opinion, but it is wrong.  In no way does 1122 say
> > that connections in persist state cannot be ABORTed.  What 1122 does
> > say is that a connection being in persist state for a long time is
> not
> > sufficient reason *by itself* to terminate a TCP connection, i.e.,
> > don't time it out like you would a connection to a non-responsive
> host.
>
> Just so that we are all clear, i want to summarize the goals of the
> draft here once again:
>
> 1. Clarify the 1122 ambiguity/stance on the sender behavior in persist
> state.
> 2. Document (for informational purpose) the consequence of this
> behavior leading to
> the DoS possibility.
> 3. Specify that the OS/application can terminate the connection in this
> state using the 793 ABORT interface.
>
> We are NOT documenting the various memory management
> considerations/issues surrounding the DoS scenario, that's left to the
> implementers discretion.
>
> We will change the section that's ambiguous regarding the sentence that
> goes "TCP itself should not take any action...".
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Tue, 25 Nov 2008 10:25:41 -0600

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Murali Bashyam
>Sent: Friday, November 21, 2008 2:34 AM
>To: Murali Bashyam; David Borman; Murali Bashyam
>Cc: Ted Faber; [email-masked]; Anantha Ramaiah (ananth)
>What are the next steps for this document to be considered a  
>WG item? Can we get some closure on this draft?

In the email thread proposing to adopt this, there were
several people who expressed resistance.  Most seemed to
agree that it's not a pressing matter for TCPM and we'd
only be providing implementation guidance.  There was only
fairly weak support for adopting this expressed by anyone
but the authors, from what I saw.  To me, it doesn't look
like the WG is expressing sufficient interest to carry
this through the process, even if it's mostly technically
accurate and has some small utility in aiding implementers.

Unless people start flooding forward to express interest
in this as being important to them and commit to doing
reviews, etc., I don't think it can be adopted as a WG item.
If anyone does strongly support the document as a WG item,
please speak up.