Problem: This paper looks at how to best provide Internet connectivity to moving (i.e., vehicular) clients in a city where WiFi is ubiquitous. Their work is tested on and tuned for a city network with many overlapping base stations and bursty and independent packet losses across senders and receivers. They assume base stations can talk to each other but are bandwidth-constrained. They also want to avoid batching since they claim it increases latency & they want to support highly interactive mobile applications.
Past approaches: The standard "hard handoff" approach is to connect to a single base station and then switch to a new, "better" one when the first connection becomes too "bad". This paper evaluates five different hard handoff strategies: RSSI, BRR, Sticky, History, and BestBS. These strategies differ in how they determine when to switch between connections:
- RSSI - base station strength (note: standard familiar metric),
- BRR - highest exponentially averaged beacon reception ratio,
- Sticky - stays with a base station until disconnected for a set time period, then picks highest signal strength,
- History - historic best average performance for a location,
- BestBS - for each 1sec period, uses BS with best predicted future 1sec reception ratio.
Number of packets delivered: AllBSes had the highest average number of packets delivered per day, but is within 25% of all the other methods except for Sticky, which (perhaps predictably) had by far the lowest. Distribution of session length: Median session length of AllBSes is 2x BestBS, 7x over BRR. However looking at the full distribution graph (Fig 3d), I'm not sure whether "median" properly captures the difference; AllBSes doesn't look that much better than BestBS on the graph. Periods of disconnection: On their drive, BRR had 6 disconnections, BestBS had 2, AllBSes had 0.
Their proposal: Inspired by the success of AllBSes, the authors propose ViFi. ViFi picks one main "anchor" base station using any strategy (their implementation uses the highest exponentially averaged beacon reception ratio like BRR). The mobile client can then designate other BSes as "auxiliary" connection points. If an auxiliary point hears a packet sent between the client & anchor but not an ACK, the aux BS probabilistically relays it. This is often better than retransmission by the original sender because (assuming bursty losses) if the original was lost then the resent packet is likely to be lost too. However, an aux tries to only relay (as modeled by the probability computation) if other auxiliaries are unlikely to relay, given that auxes with better connectivity have preference. Each BS knows the anchor and aux set for the client because it is periodically broadcast. Also, a new anchor will check for packets at the old anchor, which they call "salvaging." Note that ACKs may take longer than usual since there's an optional relay step in the middle that doesn't require retransmission. Also, packet reordering may occur; they claim that this is infrequent enough to not hurt TCP performance.
Comment: This reminds me of ExOR, although here they don't go for "luckiness" (the case where a packet goes unexpectedly far) -- they just try to fix "unluckiness" (a packet doesn't make it far enough) with eavesdropping on broadcast packets. Both need to pick a set of points to interact with, and each node needs to determine whether other nodes might be transmitting. ViFi is simpler though: it chooses a primary point (the anchor) and doesn't require slotting.
-------------------
Class notes:
Probabilistic choosing:
-- Which packet is supposed to forward?
-- Try to make probability that it is relayed = 1.
-- Trying to minimize # of redundant transmissions, but that is LESS important than making sure it is relayed -- transport layer protocols are usually resilient to duplication.
Salvaging has a big impact on performance because TCP is loss intolerant.
No comments:
Post a Comment