1 / 12

CSE 561 – Reliability

CSE 561 – Reliability. David Wetherall djw@cs.washington.edu Spring 2000. This Lecture. Routers, continued. End to End argument Retransmission timers. E2E Paper. Saltzer, Reed, Clark 1984 Captures folklore in a now classic systems paper

jadzia
Download Presentation

CSE 561 – Reliability

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. CSE 561 – Reliability David Wetherall djw@cs.washington.edu Spring 2000

  2. This Lecture • Routers, continued. • End to End argument • Retransmission timers djw // CS 561, Spring 2000

  3. E2E Paper • Saltzer, Reed, Clark 1984 • Captures folklore in a now classic systems paper • Design requires deciding what functions to implement and where to place them; E2E guides the latter • E2E is a powerful design principle, but not a law djw // CS 561, Spring 2000

  4. E2E Argument • A function might be placed in the application, network, or both. • Place it where it can be done correctly and completely, or otherwise (if it does an incomplete job) provides a significant performance gain. • Rationale for moving functions out of the network and into end-systems. An Occam’s razor. djw // CS 561, Spring 2000

  5. Example: Careful File Transfer • File transfer exposed to many kinds of errors other than network corruption (disk, software) • E2E check and retry is required for correctness • Reduces complexity of low probability failures • Strong network checks are not sufficient • So avoid them as wasteful • Q: How does file transfer work today? djw // CS 561, Spring 2000

  6. Simplicity vs. Complexity • Downsides of low-level implementation • Duplication of effort can lower performance • Optimizes network for one type of use • Upsides of low-level implementation • Partial implementation can improve performance • Avoid repeated implementation by each app djw // CS 561, Spring 2000

  7. Tensions • Non-performance aspects of network implementation • Bandwidth enforcement, firewalls, AUPs • Need to take administrative regions into account • System evolution • Transparent caching, NAT boxes • Want to administer end-systems in a scalable manner • Generic vs. per Application network support • Multicast, content distribution, active networks • Value in using network location if not a cost to all djw // CS 561, Spring 2000

  8. Retransmission Timers • Timeouts (RTO) are used to decide a packet has been lost and should be retransmitted. • Based on estimate of RTT and hence maximum likely RTT • SRTT = alpha x sample + (1-alpha) x SRTT • RTO = beta x SRTT • RTO exponential backoff for successive losses djw // CS 561, Spring 2000

  9. The Value of a Good Timer • Q: Does any of this matter? • A: Yes. Critical to performance (protocol and network) • If too large: • Detection of losses delayed, window doesn’t advance, result is low throughput, esp. on error prone links • If too small: • Early retransmissions (before the original ack arrives) • Seriously bad for the network djw // CS 561, Spring 2000

  10. Karn and Partridge (SIGCOMM’87) • Deals with retransmission ambiguity • Is ack for original or retransmitted packet? • Problem: timers were failing, this was a piece. • Can’t assume acks are always for new, always for old, or simply ignore if packet is retransmitted. djw // CS 561, Spring 2000

  11. Karn’s Algorithm • Insight: Use backoff as part of RTT estimation • Don’t use ack for retransmitted packet to calculate RTT • On loss, backoff RTO and keep using for subsequent packets until 3. • When ack for singly-transmitted packet arrives, use sample to update RTT and reset RTO • 1 avoids retransmission ambiguity, 2 ensures good samples will arrive, and 3 tells us when we get one. djw // CS 561, Spring 2000

  12. TCP Timestamps • Several TCP options added in early 1990s as part of extensions for high performance • Round Trip time Measurement • Want more than one RTT sample per window • Send timestamp with packet; receiver echoes with ack • Resolves retransmission ambiguity djw // CS 561, Spring 2000

More Related