--- Ted Faber <faber@ISI.EDU> wrote:

> On Mon, Aug 28, 2006 at 03:59:43PM -0700, MURALI
> BASHYAM wrote:
> > 
> > 
> > --- Ted Faber <faber@ISI.EDU> wrote:
> > > Why get TCP involved here?
> > 
> > Because TCP's requirement to persist indefinitely
> > creates the problem and only TCP is aware of how
> long
> > the peer has been doing zero window offering.
> 
> TCP is completely unaware of how long a client has
> been offering a 0
> receive window.  You'd have to change it to keep
> count of that.  That's
> what you're proposing, correct?  

Correct.

> 
> As an aside, RFC1122 says pretty unambiguously that
> both holding a zero
> window and probing it regularly are intentionally
> supported.

It does, and i dont understand the rationale of
probing *infinitely* as long as the client is
acknowledging the probe with a zero window. It's
possible that the authors did not have the potential
of a DOS attack when they created this mechanism. In
the scenario that i am talking abt these probes were
sometimes running for hours together and such
connections were ultimately starving out other
legitimate users traffic.

> 
> > This does not take into account the fact that
> > connections are persisting and probing for peer's
> zero
> > window which is fundamental to the discussion.
> 
> The resource your proxy is running out of is CPU to
> do window probes???
> If so, that's very surprising.  If not, can you tell
> me what your
> concern is?
> 

The resources in question are connections and buffers.
Here we are talking potentially huge numbers of them
(100000 connections and even if each connection holds
1 buffer, that's a lot of buffer memory). A mechanism
to reclaim these resources  would have to take into
account the duration of the persist state of the
connections, it can't be done blindly.

> Looking at RFC1122 Section 4.2.2.17, it's hard to
> imagine a less CPU-
> intensive way to deal with window probing than the
> exponential backoff
> algorithm suggested there.
> 
> > A TCP sender which is simply trying to probe the
> peer
> > for an indefinitely long amount of time certainly
> > stops helping the application or the system once
> > beyond some amount of time threshold. The
> threshold
> > may be different for different  applications but
> for a
> > given application and a system the threshold
> surely
> > exists.  
> 
> Without getting too philosophical, the designers of
> TCP did explicitly
> support connections that lock out transmission via a
> zero window size.
> 

I think the crux of the issue here is that this is
left to the client side application control which
means open game for hackers.

Murali
> -- 
> Ted Faber
> http://www.isi.edu/~faber           PGP:
> http://www.isi.edu/~faber/pubkeys.asc
> Unexpected attachment on this mail? See
> http://www.isi.edu/~faber/FAQ.html#SIG
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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