Re: [tcpm] Is this a problem?

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 <eblanton@cs.ohiou.edu>
To: Joe Touch <touch@ISI.EDU>
Cc: MURALI BASHYAM <murali_bashyam@yahoo.com>; tcpm@ietf.org; Lloyd Wood <L.Wood@surrey.ac.uk>
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

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
        -- Cesare Beccaria, "On Crimes and Punishments", 1764

__________________________________________________
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