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

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: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
> Murali Bashyam
> Sent: Saturday, October 04, 2008 9:49 PM
> To: David Borman; Murali Bashyam
> Cc: Anantha Ramaiah (ananth); tcpm@ietf.org; Ted Faber
> Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
>
>
>
> > -----Original Message-----
> > From: David Borman [mailto:david.borman@windriver.com]
> > Sent: Friday, October 03, 2008 2:05 PM
> > To: Murali Bashyam
> > Cc: Ted Faber; tcpm@ietf.org; 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm