<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<font face="Helvetica, Arial, sans-serif">And just to clarify a
too-hasty answer, to stop excess retransmission quickly, the app needs
to force an "unclean" TCP close, because the standard TCP CLOSE command
gets slowed by any accumulated buffering in the network.</font><br>
<br>
This just reminds us all that TCP was designed with the assumption that
the network didn't go out of its way to hold stuff in buffers to be
"helpful" - the underlying idea was "best efforts"(e.g., drop packets
early), not heroic efforts.<br>
<br>
Meanwhile, the router and link marketing guys beaver away trying to be
"helpful" and "add value" by offering offline buffering services that
apps don't need. What if we had let them use whole disk drives?<br>
<br>
On 07/06/2009 12:12 PM, David P. Reed wrote:
<blockquote cite="mid:4A52228A.3030402@reed.com" type="cite">A quick
answer:
<br>
<br>
On 07/06/2009 11:21 AM, rick jones wrote:
<br>
<blockquote type="cite"><br>
Why is TCP's waiting too long in some ways right, but 802.11's waiting
too long relatively useless? Both seem to be letting those above them
have time to make their own decisions?
<br>
<br>
</blockquote>
TCP's waiting too long doesn't hide degradation of the end-to-end
channel from the app, *because the app can close the circuit, which
halts any further retransmission*.
<br>
<br>
802.11's trying at the link layer for too long has no way for the
higher layer to tell it to stop trying.
<br>
<br>
If the higher layer can change the lower layer's behavior based on its
requirements, that's an improvement.
<br>
<br>
But please, please, please don't mistake this observation for a claim
that either TCP or 802.11 are designed to take into account the
variable needs of end-to-end apps for semantics other than
maximal-throughput FTP - that's one reason I fought for UDP (along with
the others who did as well), which exposes raw IP through a
host-mux/demux interface based on ports.
<br>
<br>
</blockquote>
</body>
</html>