1 / 15

What constitutes useful system work?

What constitutes useful system work?. Keeping our feet on the ground Injong Rhee NCSU. Gap between Systems and Theory work. Systems Practical working solutions. Glamorously put “Systems approaches.” Disparagingly put “Ad Hoc”, Engineering Tweaks/Hacks.”

tocho
Download Presentation

What constitutes useful system work?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. What constitutes useful system work? Keeping our feet on the ground Injong Rhee NCSU

  2. Gap between Systems and Theory work • Systems • Practical working solutions. • Glamorously put “Systems approaches.” • Disparagingly put “Ad Hoc”, Engineering Tweaks/Hacks.” • No well-defined metrics. What do they optimize for? • Good for specific scenarios/cases, but unknown/unproven bad corner cases. • Theory • Works for all cases within the defined scope. • Within well-defined metrics, always optimal. • But loaded with impractical assumptions and hidden performance costs. • Can’t be used in reality, at least in the current platforms.

  3. This practice continues; the gap never closes.

  4. Systems Lots of little add-ons/Hacks to TCP. E.g., ELFN, ATP,ADTCP, ADTFRC,LRED,NRED,COPAS, CAR ,Split TCP,FeW, EXACT, etc. Non-TCP based approaches Fusion (sensor), Rate limiting, CODA,C3L, IFRC, etc. Tweaking many knobs based on simple intuitions. Works well for specific setups (sensors, mesh, etc). Theory [Tassiulas and Ephremides’92] Differential-backlog based back-pressure. Many follow-up work applied for cross-layer optimization involving scheduling, routing, Congestion control, power control. Throughput-optimal solving an NP-hard scheduling problem in realistic interference models. Requires routing to almost random locations before congestion. Works only for throughput. Congestion Controlas an example

  5. Closing the gapSystems Approaches • Borrow intuitions from theoretical results. • Heuristics designed to overcome impractical components, but still congruent with other features of the theoretical schemes. • Optimized to the same direction that the original components are intended to. • Results: Improved performance without much loss of generality (without bad corner cases).

  6. WiseNet Testbed • 50 nodes of Soekris 4826, 266Mhz CPU and 128MB SDRAM. • MAC is Atheros IEEE 802.11 chipset (5212) using the MadWifi-NG driver.

  7. Video Demo

  8. Queue Differential (QD) Each node overhears neighbors’ transmission and for each active destination queue, computes the difference of queue sizes for each destination queue. E.g., Node C for a destination R: QDC(R) = QC(R) - QF(R). Source A C D B F congestion R QD=1 QD=2 QD=3 F E

  9. Scheduling Schedules the link with the largest queue differential first. Queue Differential (QD) removes the dependence on absolute queue sizes. MAC provides a higher priority on the packet whose next hop link has larger QD. Source A C QD = 2 B QD = -1 QD = 3 D

  10. Backpressure and source rate control Upstream gets backpressure because its transmission gets lower priority and thus, its queue builds up. As a result, it throttles its transmission rate. Ultimately, backpressure can propagate to the source and the source simply rate-controls based on its queue size. backpressure A C B source D No Explicit End-to-End Feedback!!

  11. DiffQ Architecture (bird’s eye view)‏

  12. Practical results providing rules of thumb for performance upper bounds • Engineers need to know how much performance gain certain features provide in real systems. • Topology control is a good example • Much theoretical work exists using graph theory, but tons of assumptions about MAC and interference models. • But what message do we have for practitioners? It is good, but how much? What do you typically see when you deploy a practical implementation of it?

  13. Know Thee Performance Metrics • Most notorious metric: Fairness. • Most system work is vague about this; typically they look for “equal” performance. • Example: • MAC: all competing nodes have the same throughput? • Why equal throughput? Not all nodes can transmit well. Different Interferences, Topologies, etc. Wouldn’t proportional share or equal time more approproate? • Congestion control: why all flows should have the same through? Some flows are under more interferences and “traffic” because of different paths they take.

  14. No “point” solutions • Controls only one or two knobs and improve performance on one or two metrics, but might hurt the overall performance. • MAC • Modify MAC to provide certain performance guarantees, but what about other applications requiring different metrics? • Shouldn’t MAC remain general enough, yet flexible to support various application needs at the same time? • Desirable features: expose knobs to upper-layers and let them fix the knobs. • Congestion control

  15. Building easy-to-use yet realistic platforms to test and validate.

More Related