Re: [tcpm] TCP zero window timeout?

["Kuthonuzo Luruo (STSD)" <[e-mail]>]

On Sat, 2006-08-26 at 16:05 -0700, MURALI BASHYAM wrote:
> Fernando
> 
> I collaborated with mahesh on this, so let me try
> making the case for it a little better.
> 
> The problem was found on a TCP proxy, which does not
> have any applicaton awareness. In fact application
> awareness is not a goal in that environment. Hence the
> TCP level solution.
> 
> Having said that, i'd say this timeout is in the same
> spirit as the upper bound on the retransmit mechanism
> of TCP. TCP could indefinitely retransmit and have the
> application timeout too, correct? The problem is that
> TCP has a persist state which can potentially exist
> infinitely long  and which lends itself to abuse by a
> malicious peer. Just based purely on this
> consideration, don't you think TCP should have a
> mechanism that reduces the impact of this problem by
> either limiting the number of probes (a la retransmit
> timeout) or the duration. And the application can turn
> it on per connection via a socket option and set a
> value which makes sense for that application, so there
> is per application per connection control anyway.

Several OSes do include a socket option SO_SNDTIMEO, that can be set by
an application to specify the amount of time a transmit function blocks
when flow control prevents the transmission of data. 

-thonuzo

> 
> Murali
> 
> --- Fernando Gont <[e-mail]> wrote:
> 
> > At 21:00 25/08/2006, Mahesh Jethanandani wrote:
> > 
> > >The situation I was referring to is a little
> > different and applies 
> > >to persist timer. In our situation the client stops
> > reading data. 
> > >These clients are machines out in the Internet and
> > as such the 
> > >server has no control over their behavior. So while
> > there is 
> > >unacknowledged data, it is not that the client is
> > not acking any 
> > >data. It is responding to the probe but that it
> > continuously 
> > >advertises a window of zero.  There is currently to
> > my knowledge no 
> > >timeout for this state for the server. This can
> > manifest itself as a 
> > >DOS situation if there are several such connections
> > where the server 
> > >is forced to hold data.
> > 
> > I'd argue that this should be handled by an
> > application-level timer.
> > 
> > The problem with the scenario you point out is that
> > there will always 
> > be one more way to do the same thing.
> > 
> > If we're talking about connections wasting
> > resources, there are many 
> > protocols (POP3, SMTP) in which after the initial
> > greeting by the 
> > server, the client is supposed to go ahead. In all
> > those cases, the 
> > client could just sit there. And only an
> > application-layer timeout 
> > would help you.
> > 
> > I'm not sure how many servers implement this type of
> > 
> > application-layer timer. But there are some (Apache)
> > that I have 
> > checked, and do.
> > 
> > Nevertheless, I'm interested in the behaviour you
> > described. Is it 
> > supposed to be malicious activity?
> > 
> > Kindest regards,
> > 
> > --
> > Fernando Gont
> > e-mail: [e-mail] || [e-mail]
> > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE
> > A9EF D076 FFF1
> > 
> > 
> > 
> > 
> > > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/tcpm
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tcpm


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