1 / 26

Slick Packets

Slick Packets. Giang Nguyen † , Rachit Agarwal † , Junda Liu ‡ , Matthew Caesar † , P. Brighten Godfrey † , Scott Shenker ‡ † University of Illinois at Urbana-Champaign ‡ University of California, Berkeley SIGMETRICS 2011. Approaches to packet routing.

necia
Télécharger la présentation

Slick Packets

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. Slick Packets Giang Nguyen†, Rachit Agarwal†, Junda Liu‡, Matthew Caesar†, P. Brighten Godfrey†, Scott Shenker‡ † University of Illinois at Urbana-Champaign ‡ University of California, Berkeley SIGMETRICS 2011

  2. Approaches to packet routing • Network-controlled routing (NCR): the network controls the route • Analogy: taking a bus, one travels route determined by transit agency • Standard IP next-hop routing/forwarding • Source-controlled routing (SCR):users have some or total control of the route • Analogy: when driving, one determines own route • More flexible enables better performing routes, increases network provider competition, etc.

  3. Failures in the network • Daily occurrences: 60% of the time, some link fails in next 10 minutes [Iannaccone02] • Cause “routing convergence”  tens of seconds of packet loss while underlying network remains connected [Kushman07, Wang06] • Adversely affect real-time applications (e.g., VoIP, video conferencing, online games)

  4. Fast failure reaction • Within network-controlled routing paradigm: • Reduce routing convergence period • “Fast reroute” : use alternate paths to forward packets during routing convergence (e.g., MPLS Fast Reroute, SafeGuard, R-BGP) • Within source-controlled routing paradigm: • Sources monitor path quality: too low  switch path (e.g., Path Splicing, Pathlet Routing) • Takes on order of RTT to react • No “fast reroute” technique

  5. SlickPackets • Source-controlled routing protocol with alternate paths in packet headers • Best of both worlds • Flexibility of source-controlled routing • Fast failure reaction of network-controlled routing using alternate paths

  6. Design

  7. Design overview

  8. Design overview R2 R1 R5 Dst Src R4 R3

  9. Key steps • Dissemination of network map • Leverage past work (NIRA, Pathlet Routing) • Selection of the forwarding subgraph • Encoding of forwarding subgraph in packet header • Forwarding of packet

  10. Forwarding subgraph (FS) • Represents subset of network along which routers can forward packet • Is a DAG to avoid forwarding loops • Source may select FS with enough redundancy to avoid failures • Use case: shortest paths & avoid single-link failures • Selects a shortest “primary path” • Selects for each node on primary path a shortest “alternate path” to destination in case its primary next-hop link fails

  11. FS selection example R2 R2 R1 R5 R1 R5 R3 R4 Forwarding subgraph Network map Suppose s selects R1R2R5 as primary path

  12. FS selection example R2 R2 R5 R1 R5 R1 R4 R3 R4 Forwarding subgraph Network map For R1, s selects R1R4R5 as alternate path

  13. FS selection example R2 R2 R1 R1 R5 R5 R4 R3 R4 Forwarding subgraph Network map For R2, s selects R2R4R5 as alternate path

  14. Forwarding subgraph encoding Designed two formats • “Direct”: directly serializes the forwarding subgraph • A more general format • “Default”: encodes “segments,” one for each primary node • More efficient in most of cases we evaluate

  15. Failure notification • So far, SlickPackets enables packets to slip around failed links • But packets reach failure  might be sub-optimal • “Reactive” notification • Router adjacent to failed link sends control message to source of packet that tries to use link • Or, destination can notify source end-to-end

  16. Evaluation

  17. Encoding size eval methodology Topologies: • Latency-annotated Sprint ISP (315 nodes, 972 links) • Unweighted AS-map of the Internet (>30,000 nodes, >75,000 links) • Unweighted router-level map of the Internet (>190,000 nodes, >600,000 links)

  18. Encoding size for AS-level map • 99% less than 26 bytes • Maximum of 50 bytes • Reasonable for large packets

  19. Failure reaction simulation • Metric: packet stretch(= ratio of packet life time to latency of shortest available path) • Simulation run for each link: • All nodes send packets to all other nodes every 1ms • Fail the link  evaluate all connected src-dst pairs • Protocols: “Vanilla” source routing, SafeGuard, SlickPackets

  20. Vanilla source routing ICMP-style control packet Data packet Src Dst • Dropped packets  resent when src knows of failure Failed link

  21. SafeGuard Control packet (i.e., LSA) Data packet Src Dst • No dropped packets • All routers upstream from failure redirect packets

  22. SlickPackets ICMP-style control packet Data packet Src Dst • No dropped packets • Only router adjacent to failure redirects packets

  23. Average stretch for Sprint ISP

  24. Average stretch for Sprint ISP

  25. Average stretch for Sprint ISP SlickPackets achieves packet stretch comparable to SafeGuard, an NCR protocol

  26. Conclusion SlickPackets • Is a source-controlled routing protocol • Enables fast reroute • Specifies alternate paths in packet header • Has reasonable packet header overhead Future work: • Hardware implementation • Congestion as a failure

More Related