Re: [tcpm] Is this a problem?

[MURALI BASHYAM <[e-mail]>]

Writes may not block here, since there is space in the socket send buffer to accomodate the response tail.
We can't assume blocking writes to solve this issue.

If writes do not block, and the (tail of)  response fits in the send buffer queue, now the responsibility for
managing that data  is completely TCP's. TCP now needs an indication from the application to decide whether
to try to send that data indefinitely when the receiver continually advertises zero window or it has to implement a time bound as
requested by the app.  It's that simple, isn't it?

Murali

----- 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