Re: [tcpm] Is this a problem?

[Joe Touch <[e-mail]>]

MURALI BASHYAM wrote:
> Writes may not block here, since there is space in the socket send buffer to accomodate the response tail.

Sure. In which case you have a background timer. Either way, your
problem is solved.

You seem to want to interpret this as a unique DOS attack based on
TCP-specific info that differentiates it from a connection that's just
slow. I agree with Ethan - if you have limited resources, you terminate
either way. If not, you hang around until you need to recover state.
Either way you don't need to differentiate the two, and an app timer
suffices.

Joe


> ----- Original Message ----
> From: Joe Touch <[e-mail]>
> To: MURALI BASHYAM <[e-mail]>
> Cc: Ethan Blanton <[e-mail]>; [e-mail]; Lloyd Wood <[e-mail]>
> Sent: Tuesday, November 6, 2007 2:27:18 PM
> Subject: Re: [tcpm] Is this a problem?
> 
> 
> Yes, HTTP has head of line blocking on persistent connections.
> 
> If HTTP doesn't want to hang that connection forever on a pending
> transfer, use blocking writes and terminate the connection on a
>  timeout.
> 
> If HTTP doesn't want HOL blocking, don't use persistent connections.
> 
> Joe
> 
> MURALI BASHYAM wrote:
>> The problem is also harder to solve in the HTTP context, for
>  persistent connections, where the server
>> can write the tail of the HTTP response to the connection send
>  buffer, and then it keeps the connection around
>> (i.e no app close) waiting for a new HTTP request from any clients
>  out there. It has
>> no way of detecting whether forward progress has been made for that
>  particular response, because it is now
>> completely in TCP's send buffer to deliver it. These are scenarios
>  where it seems acceptable for TCP to accomodate
>> what the application wants (don't hang indefinitely to deliver that
>  response).
>> Murali
>>
>> ----- Original Message ----
>> From: Ethan Blanton <[e-mail]>
>> To: Joe Touch <[e-mail]>
>> Cc: MURALI BASHYAM <[e-mail]>; [e-mail]; Lloyd
>  Wood <[e-mail]>
>> Sent: Tuesday, November 6, 2007 11:08:45 AM
>> Subject: Re: [tcpm] Is this a problem?
>>
>>
>> Joe Touch spake unto us the following wisdom:
>>> MURALI BASHYAM wrote:
>>>> We want to limit the timer to the sender's persist state only, any
>>>> other timeout overloads the semantics of the application, and may
>>  also
>>>> cause unnecessary timeouts for the application. In fact there are
>>>> instances where the application may not even have the connection
>>  state
>>>> around to implement the timout correctly, like the tail of a long
>>  HTTP
>>>> response. After sending the tail of the response, the application
>>  can
>>>> close the connection and release its connection memory, during this
>>>> window only TCP has the connection state. We've done a lot of
>>  testing
>>>> and design for handling all these cases, and to implement this
>>>> correctly, we need TCP's involvement.
>>> It still sounds like you have a poorly written application to me;
>>  anyone
>>> else?
>> This comment of Murali's, specifically, is a case that the
>  application
>> *cannot* (portably or cleanly) handle, at least under the Berkeley
>> sockets API.  He is correct that once an application writes the end
>  of
>> its data and calls close() or shutdown(), the TCP socket may persist
>> indefinitely in the kernel, and the application would never know (if
>> there are no application-level acknowledgments, as there are not in
>> simple HTTP responses).
>>
>> It does not seem unreasonable to add a zero-window timeout tunable to
>> any given TCP implementation; I don't necessarily think it is a TCP
>> standardization issue, however, as there is no wire impact.
>>
>> Ethan
>>
> 
> 
> 
> 
> 
> __________________________________________________
> 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