1 / 30

Diverse Network Services and Remaining Challenges

Diverse Network Services and Remaining Challenges. SRCCS Winter 2005 Workshop on Internet Modeling and Analysis Sue B. Moon Division of Computer Science Dept. of EECS KAIST. Diverse Data Sets in Korea. Data from major ISPs Non-existent in public Data from academia

michon
Télécharger la présentation

Diverse Network Services and Remaining Challenges

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. Diverse Network ServicesandRemaining Challenges SRCCS Winter 2005 Workshop on Internet Modeling and Analysis Sue B. Moon Division of Computer Science Dept. of EECS KAIST

  2. Diverse Data Sets in Korea • Data from major ISPs • Non-existent in public • Data from academia • DAGMON traces at KAIST • Long-term, sampled flow-level traces at POSTECH • 4-month-worth NetFlow traces at CNU • Others • 3G video streaming service data • 2-day packet-level traces from a home network

  3. Diverse Data Sets in Korea • Data from major ISPs • Non-existent in public • Data from academia • DAGMON traces at KAIST • Long-term, sampled flow-level traces at POSTECH • 4-month-worth NetFlow traces at CNU • Others • 2-day packet-level traces from a home network • 3G video streaming service data

  4. 2005.11.23 at KAIST In Bits/Sec No. of Pkts / sec Others Others P2P P2P FTP HTTP FTP

  5. 2004.12.9. at KAIST In Bits/Sec No. of Pkts / sec Others Others P2P P2P HTTP FTP

  6. REMOVE after chat with SY • Previous slides upstream or downstream? • According to JH Youn • Upstream 70%/85% (Bytes/Pkts) p2p • Downstream Web and VOD more dominant that p2p.

  7. Home Networking in Korea • Architecture • Simple, tree-like topology • To each home = 100ME • Internal links = 1GE • Outbound speed = OC-3 or up • Reality in new apt complexes • Control home appliances thru the net • washing machine, gas stove, lights, heater/airconditioner, door lock • by PDAs at home or remotely by cellphones/web access • Replace DSL/cable lines • Will be "backbone" for home ubiquitous sensor network • Need for remote monitoring • Lack of resources

  8. 2004.12.11. at a Home Network

  9. Video Streaming over 3G • Goals of Monitoring • To satisfy every user: • High revenue-generating customers • More focus on per-user performance • Challenges • E2E performance segmented over cellular and wired networks • No integrated monitoring solutions yet • No good metric for overall/single-user performance

  10. Provisioning for Interactive Streaming • Interactive Streaming • Not a driving force behind b/w • A candidate for growing revenue • Examples • VoIP gradually taking over PSTN traffic • Remote video viewing at door by cell phone • Online game traffic • "Good" routing more important than bandwidth

  11. Routing in the Internet Inter-domain: policy-based routing Intra-domain: shortest path routing

  12. Issues in "Good" Routing • Misbehaving routing protocols • BGP misconfigurations • Pathological behaviors • Frequent changes • Even under normal circumstances • Transient behaviors • Inter/intra-domain routing not well understood

  13. Scenario for a Transient Routing Loop In Normal Operation

  14. When a link fails, R1 is the first to detect.

  15. R3 is updated before R2.

  16. Finally R2 is updated, and the loop is resolved.

  17. CDF of Routing Loop Duration in Time

  18. VoIP experimental setup [Boutremans2002] • Traffic injected in the network: • 200 byte UDP packets • every 5ms. • Packets captured and timestamped at end-systems. • Traceroute runs continuously during the experiment.

  19. Information Sources • IS-IS & BGP listener logs • Router logs from both ends of “failing” links • Controlled bi-directional VoIP traffic between Reston and ATL • SNMP data

  20. ~3.4ms ~2.6ms 3 links up 2 links down 2 links up 3 links down Delays (1 sec timescale)

  21. When the two interfaces went down … 6.6 seconds

  22. Traffic “black-holed” for 0.975 seconds Traffic “black-holed” for 1.745 seconds For 30 secs packets follow a shorter path When three links came back up …

  23. Approaches To Fix It • Fine-tuning parameters • Timer values [Alattinoglu2002] • Modify Routing Protocols • Suppress advertisement and perform local rerouting using a backwarding table [Lee04] • Centralized path computation [Feamster04,Rexford04]

  24. Our Approach • Key Idea: • Find disjoint overlay path and send duplicate packets • Assumptions • Sender and receiver both within an AS • Bidirectional link weights • Extra income for extra b/w consumption • Pros and cons • Advantages • No modification to current infrastructure • Selective use by only those that need it • Disadvantages • Extra b/w consumption

  25. source destination Basic Ideas candidate relay nodes!!!

  26. Resilient to Failures

  27. Future Work • Answer questions raised about diverse data sets • Find best places for relay nodes in Inter-domain

  28. BACKUP

  29. Summary: Local Convergence • Convergence delay during failures hurts more • After IS-IS converges, extra delay due to FIB update

  30. Causes and Open Questions • Why only after 30 secs? • spf-interval set to 30secs • What caused the 1.745 secs disruption? • Unknowsn in GSR architecture • What is the right timescale to propagate good news?

More Related