[e2e] Some thoughts on WLAN etc., was: Re: RES: Why Buffering?

[David P. Reed]

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.

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.

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?

On 07/06/2009 12:12 PM, David P. Reed wrote:
> A quick answer:
>
> On 07/06/2009 11:21 AM, rick jones wrote:
>>
>> 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?
>>
> 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*.
>
> 802.11's trying at the link layer for too long has no way for the 
> higher layer to tell it to stop trying.
>
> If the higher layer can change the lower layer's behavior based on its 
> requirements, that's an improvement.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20090706/e99b7902/attachment.html