Re: [Aironet] Re : Firmware/packet loss/802.11 (long)
Status: Inactive
Brought to you by:
breed
From: Jean T. <jt...@bo...> - 2000-02-15 20:00:39
|
On Tue, Feb 15, 2000 at 07:14:50PM +0100, Jean-Pierre Ebert wrote: > Hi Jean, hi all, > > > The *BIG* problem of those papers are outdated with regards to > > the hardware we are talking about, because they don't consider MAC > > level retransmissions. > > Without MAC level retransmission, you would reach their > > conclusions (even though I much prefer SNOOP to Split-TCP). With MAC > > level retransmissions, the conclusion might be different. > > By the way, SNOOP is a form of MAC level retransmission, and > > their paper shows that it out-perform other solutions. Of course, with > > 802.11 MAC acs, we shouldn't need SNOOP any more. > > Wait wait, first the paper are not that outdated as you think. Just > realize the general well expressed idea: If one have retransmissions > below TCP (whatever level it will be (LLC/MAC)) than one has to ensure > that the retransmit timers on TCP level and and the one on the lower > levels should be harmonized. Just a small example: Think of a packet > which got lost on the radio link. The MAC retransmit this packet several > times until it was succesfully delivered (this may take several seconds > with aironet4800 cards!!!). In between the retransmit timer of TCP times > out (retransmit timer of TCP are dynamic from 200ms - several seconds) > and TCP retransmit the packet. The point is, although the MAC has > successfully delivered the packet, TCP will retransmit it! So the same > packet might be transmit several times. This is what the performance > degradation makes. Sight... You've got a way to miss most of the important information that I put in my e-mail. Please, please, please, read carefully ! If you go back to my previous e-mail (the first one), you will see that I describe exactly this effect (wow, so I could I possibly ignore it !). > Three conclusions could be drawn: > - Leave retranmission to higher level protocols (not on MAC). The > problem with this method is that retransmission on MAC level is the most > efficient way to recover from channel errors. So let see what the next > two points bring I'm sorry, but you *need* MAC level retransmissions. If you look into the SNOOP papers, they made extensive study and benchmark to prove that a good link layer retransmission mechanism was outperforming any other scheme done at the TCP level. More details at : http://http.cs.berkeley.edu/~hari/papers/ton.ps > - Harmonize MAC level and TCP Timeout Timers. I never read a paper about > that this is definitely a topic for research and might improve TCP > performance significantly. I have some rather hazy ideas how to do that. > Whoever is interested in that topic, can contact me. Because you never read my note and never looked into the SWAP protocol. You see, I was the first person to propose MAC retransmissions based on a timer instead of the retry count for this precise reason ! So simple that it's easy to overlook it. And of course, nobody cares... If you look into the SWAP protocol, you would realise that there is no maximum number of retry but only a time to live for packet to be transmitted (5.7.11.4.2). And if you look carefully, you would realise that this time to live is 100 ms (15.2). What an amazing coincidence ! More details are in : http://www.hpl.hp.com/personal/Jean_Tourrilhes/Papers/SWAP.TCP.pdf After that, you can try to be more clever and increase this timeout when you feel that TCP doesn't care. But that's optimisation.. So, what do you think of this neat trick ? Is it hazy enough ? > - Tell TCP about transmission state of a packet (a not very handy > solution). From the SNOOP paper (see above), you can see that *if* your link layer retransmission mechanism is well designed, it can be perfectly transparent to TCP/IP. > Snoop (also the indirect TCP approach has it's advantages) is a great > thing. It does already a this harmonization, whereas the focus goes a > bit in another direction but not on the MAC level(!). The most > efficient approach to recover from radio link errors still are MAC > level retranmission with all its problems. That's why we are trying to remove problem from MAC retries. Note that for me SNOOP is a link level retransmission, so very similar to the MAC retries as done in 802.11. One of the problem with SNOOP is that it allow desequenced TCP packets (retry of packet N is sent after packet N+1). My studies have shown that desequenced packet trigger the TCP fast retransmission mechanism (and if you look on how TCP fast retry is designed, it's perfectly logical). That's why in SNOOP they have to supress TCP acks and to do all this ugly things, to hide the fact that they desequence packet. On the other hand, if you keep packet strictly in sequence, the interaction between MAC retries and TCP retries are more straighforward and you don't trigger TCP fast retransmissions. That's why I insist (see my first e-mail) on keeping packet stricly in sequence (at least within each TCP connection), and I put it as a strong requirement in SWAP. So, stop-and-go is in fact a better solution at the MAC level than go-back-N (amazing, isn't it ?). So, how do you feel about keeping packets in sequence ? Note : I don't know how people do implement their MAC retry mechanism, but I know for a fact that one manufacturer doesn't enforce that packets are sent in sequence. What about Aironet ? > See also a paper from my colleague related to that topic: > > M. Schläger, B.Rathke, S. Bodenstein, A. Wolisz; > " Advocating a Remote Socket Architecture for > Internet Access using Wireless LANs" > "accepted for publication in Mobile Networks and > Applications (The Journal of special Issues on > mobility of systems, users, data and Computing), > Special Issue on Wireless Internet and Intranet > Access, to appear Published by: Balzer Science > Publishers/ACM Is it on the web ? > see here > http://www-tkn.ee.tu-berlin.de/publications/pub.html > and > http://www-tkn.ee.tu-berlin.de/~ebert/publication.html I will look into that... > No, my father is from a former french colony (Vietnam). From there is my > name, the rest of mine is german all the way. Whereabout in Germany. I've got some friends around Stutgart... Have fun... Jean |