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

[rick jones]

On Jul 6, 2009, at 6:55 AM, David P. Reed wrote:
> In an 802.11* LAN (using standard WiFi MAC protocols), there is one  
> of these"declared down", whether you are using APs or Virtual LANs  
> or AdHoc mode (so called) or even 802.11s mesh.    Since 802.11  
> doesn't take input from the IETF, it has no notion of meeting the  
> needs of end-to-end protocols for a *useful* declaration.  Instead,  
> by studying their navels, the 802.11 guys wait a really long (and  
> therefore relatively useless in terms of semantics) before declaring  
> a WLAN "link" down.  Of course that is a "win" if your goal is just  
> managing the link layer.
>
> What would be useful to the end-to-end protocol is a meaningful  
> assessment of the likelihood that a packet will be deliverable over  
> that link as a function of time as it goes into the future.   This  
> would let the end-to-end protocol decide whether to tear down the  
> TCP circuit and inform the app, or just wait, if the app is not  
> delay sensitive in the time frame of interest.
>
> Unfortunately, TCP's default is typically 30 seconds long - far too  
> long for a typical interactive app.  And in some ways that's right:  
> an app can implement a shorter-term "is the link alive" by merely  
> using an app layer handshake at a relevant rate, and declaring the  
> e2e circuit down if too many handshakes are not delivered.  If you  
> think about it, this is probably optimal, because otherwise the end- 
> to-end app will have to have a language to express its desire to  
> every possible link along the way, and also to the "rerouting"  
> algorithms that might preserve end-to-end connectivity by "routing  
> around" the slow or intermittent link.
>
> Recognize the "end to end argument" in that last paragraph?   It  
> says: we can't put the function of determining "app layer circuit  
> down" into the different kinds of elements that make up the Internet  
> links.  Therefore we need to do an end-to-end link down  
> determination.  And in fact, if we have that, we don't need the link  
> layer to tell the ends when they are down.  So the function of "app  
> layer circuit down" should NOT be required of the network elements.


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?

rick jones
> Wisdom teeth are impacted, people are affected by the effects of  
> events