|
|
--- Caitlin Bestler <caitlinb@xxxxxxxxxxxx> wrote:
> MURALI BASHYAM wrote:
> > Fernando
> >
> > Today there is nothing that prevents a client side
> > application from simply stopping to read the TCP
> receive
> > socket buffer and causing the offered window to go
> down to 0,
> > and thus causing the sender to hold a large send
> queue worth
> > of data and probe forever. If this is done by a
> large number
> > of clients against the same server, u have a
> distributed DOS
> > attack on that server. We have seen this in
> practice.
> >
> > To answer an earlier question u had raised, the
> application
> > cannot timeout on this connection because it does
> not know
> > when the connection enters and leaves the persist
> state, only
> > TCP knows that. The application can definitely
> decide the
> > timeout value, but TCP needs to implement the
> timer because
> > only it is aware of the state of the peer.
> >
>
> True, but why does TCP need any wire protocol
> modifications to
> implement such a timeout locally?
It does not need any wire protocol modifications, but
the intent of this discussion is whether it is
worthwhile to document this at all and if so as a good
practice or as an informational RFC so that
implementers are aware of the issue and potential
solutions and so on.
Murali
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/tcpm
|
|