Resource Allocation. with slides from Leon-Garcia and Widjaja, Shenker and Stoica. Stefan Schmid - 1

Transcription

1 Resource Allocation with slides from Leon-Garcia and Widjaja, Shenker and Stoica Stefan Schmid - 1

2 Where we are now Goals: Identify, study common architectural components, protocol mechanisms Synthesis: big picture Depth: important topics not covered in introductory courses Overview: Signaling State Multiplexing / Resource Allocation Randomization Indirection Service location Network virtualization What does multiplexing mean? Resource allocation / multiplexing issues seen so far...? Stefan Schmid - 2

3 Where we are now Goals: Identify, study common architectural components, protocol mechanisms Synthesis: big picture Depth: important topics not covered in introductory courses Overview: Signaling State Multiplexing / Resource Allocation Randomization Indirection Service location Network virtualization Efficient sharing (=multiplexing) of resources using TCP congestion control, (time division) multiplexing of telephone line, medium access in Ethernet or wireless networks, explicit reservations using RSVP,... Stefan Schmid - 3

4 Sharing = Multiplexing Multiplexing: sharing resource(s) among users of the resource. Users Resources In this lecture: The Resources are Bandwidth (Link capacity) Queues (Buffer storage) The Users are Phone calls TCP/UDP flows, packets Other types of resources: CPU Storage Frequency spectrum and other types of users? Stefan Schmid - 4

5 Example: Shared link / queue H1 R1 R2 H4 H2 H5 H3 R1 output queue 1.5 Mbps bandwidth H6 Users hosts, servers, phones,. Resources queues (size), links (bandwidth), Question: How to allocate bandwidth to different users in this scenario? Fair and equal? One after other? Priorities? Best effort? It depends?... Stefan Schmid - 5

6 From Multiplexing to QoS Basic facts of life: Bandwidth is finite Cannot support traffic demands beyond capacity 1 Mbps phone R1 R2 FTP server 1.5 Mbps Example: 1Mbps IP phone, FTP share 1.5 Mbps link What could be resource allocation issues here? Stefan Schmid - 6

7 From Multiplexing to QoS Basic facts of life: Bandwidth is finite Cannot support traffic demands beyond capacity 1 Mbps phone R1 R2 FTP server 1.5 Mbps Example: 1Mbps IP phone, FTP share 1.5 Mbps link bursts of FTP can congest router, cause large delays/audio loss Phone: either minimal quality or not at all everything else does not make sense (file transfers more flexible...) => not delay tolerant, not elastic How to guarantee phone quality at any time (independently of other traffic)? Move away from the best-effort paradigm provide ``Quality of Service (QoS) (e.g., by explicit reservations) Stefan Schmid - 7

8 QoS: What is it? QoS Network provides applications with levels of performance guarantees (may be needed for applications to function). Types of guarantees (service classes) Best-effort (elastic apps) Hard real-time (real-time apps) e.g., bounded loss / delay Soft real-time (tolerant apps) e.g., probabilistic loss / delay How to implement QoS? Five principles any ideas? Stefan Schmid - 8

9 Five Principles? What information is needed to guarantee service? User s demand for resource... Make contract: If your demand is like this, my service is like that! What if two applications contend for resource, one w/o QoS and one w/ QoS? Prioritize What if application does not conform to contract? (E.g., inputs more?) Need to isolate from other apps! (Have fixed resource reservations for other applications ) What if more users arrive requesting QoS services? At some point, need to perform admission control, i.e., reject... How to ensure efficiency despite isolation? Make reservations only virtually, i.e., in times reserved resource is not needed it can be used by other apps! Stefan Schmid - 9

10 Principle 1. Make Contracts, Give Service! Two 1Mbps IP phones share 1.5 Mbps link For QoS, I need to know requirement of apps! Applications must specify: 1) how much bandwidth they need, 2) what levels of guarantees they want 1 Mbps phone R1 R2 1 Mbps phone Principle 1 (Contract) 1.5 Mbps Traffic/guarantees specification In order to guarantee a certain service (or reject the request), routers need traffic specification: if arriving traffic is such and such, I promise this and that (service contract). Stefan Schmid - 10

11 Principle 2. Traffic Classification 1Mbps IP phone, FTP share 1.5 Mbps link bursts of FTP can congest router, cause audio loss how to handle? want to give priority to audio over FTP 1 Mbps phone R1 voice FTP packets R2 FTP server 1.5 Mbps packet marking Principle 2 (Classification) Packet marking needed for router to distinguish between different classes; and router policy to treat packets accordingly. Stefan Schmid - 11

12 Principle 3. Traffic Isolation What if applications misbehave (audio sends higher than declared rate)? Want to force source to adhere to traffic specification 1 Mbps phone R1 R2 FTP server 1.5 Mbps link packet policing / shaping Principle 3 (Isolation) Provide protection (isolation) for one class from others! Stefan Schmid - 12

13 Principle 4. Call Admission Bandwidth is finite Cannot accept more requests than resources available so to provide isolation, some flows have to be rejected 1 Mbps phone R1 R2 1 Mbps phone 1.5 Mbps link Principle 4 (Call Admission) Call admission: network may block call (e.g., busy signal) if it cannot meet needs. Stefan Schmid - 13

14 Principle 5. Resource Sharing Allocating fixed (non-sharable) bandwidth can be inefficient if flows don t use it. Solution? Make isolation virtual, give resource to others in times it is not used! 1 Mbps phone R1 1 Mbps logical link R2 FTP server 1.5 Mbps link 0.5 Mbps logical link Principle 5 (Efficiency) While providing isolation, it is desirable to use resources as efficiently as possible! Stefan Schmid - 14

15 Service Classes vs. Principles Which principle needed for which QoS type? Traffic / Guarantees Specification Traffic Classification Traffic Isolation Call Admission Resource Sharing Best Effort Yes/No????? Hard real-time????? Soft real-time????? Stefan Schmid - 15

16 Service Classes vs. Principles Traffic / Guarantees Specification Traffic Classification Traffic Isolation Call Admission Resource Sharing Best Effort No No No No No Hard real-time Soft real-time Yes Yes Yes Yes nice to have Yes Yes Yes Yes nice to have Stefan Schmid - 16

17 QoS: Spectrum and Dimensions QoS can come in many forms! We will consider techniques for some of this spectrum in more detail now! resource unavailability block, drop queue Other dimensions? time granularity fairness... request granularity statistical reservations on demand packet burst call guaranteed reservations (duration and granularity) shared among class per user user granularity Stefan Schmid - 17

18 QoS Spectrum: Outline Scheduling (e.g.?) Which packet to choose and process next from queue! E.g., how does scheduling work in the TEL mensa, at a red light, at a crossroad...? How fair are these scheduling solutions? And how efficient? Policing (e.g.?) Ensure that user inputs traffic as specified in the contract! Admission Control (e.g.?) How many calls can be admitted under peak rate admission control vs statistical admission control? General class-based link sharing (multiplexing) Scheduling framework to efficiently regulate flow classes Concrete IETF proposals to do things in practice IntServ DiffServ Focus on packet-level multiplexing! Stefan Schmid - 18

19 FIFO Scheduling Scheduling = What packet in queue to choose next to send on link! Example? FIFO (first in first out) scheduling send in order of arrival to queue real-world example: traffic before stop sign discard policy: Tail drop: drop arriving packet RED (random early detection): drop randomly, earlier than needed How fair is this policy? Under different data rates? Etc. Stefan Schmid - 19

20 Priority Scheduling Strict priority scheduling: transmit highest priority queued packet Multiple classes (and queues!) with different priorities Class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc. Real world example: Berghain vs walk-ins arrivals time packet service departures 1 time Two variants: with and without preemption? When 4 arrives, 2 is allowed to finish! => w/o! Stefan Schmid - 20

21 Round Robin Scheduling Round robin scheduling: Again, multiple classes, but without priority! Cyclically scan class queues, serving one from each class (if available) Real world example: 4-way stop (distributed scheduling) Example with 2 classes (red and green): Serve red class twice since green class empty!! Stefan Schmid - 21

22 WFQ Scheduling Weighted fair queuing: generalized Round Robin each class gets weighted amount of service in each cycle implemented in many routers today and important for many QoS protocols Stefan Schmid - 22

23 Start 9. Juanuar 2013 Stefan Schmid - 23

24 Stefan Schmid - 24

25 Excursion: Fairness (1) How to divide a resource fairly? Philosophical question many notions of fairness exist! Which flow should get what share? A B C C D Assume: capacities = 1 Stefan Schmid - 25

26 Excursion: Fairness (1) How to divide a resource fairly? Philosophical question many notions of fairness exist! All 1/3 fair? Well, yes, but left link not fully used! A 1/3 B C C D 1/3 1/3 1/3 Stefan Schmid - 26

27 Excursion: Fairness (1) How to divide a resource fairly? Philosophical question many notions of fairness exist! Better? Now what if flow B actually only needs 1/6 th? Waste to give it more A 1/3 B C C D 1/3 1/3 2/3 Stefan Schmid - 27

28 Excursion: Fairness (1) How to divide a resource fairly? Philosophical question many notions of fairness exist! What if flow B actually only needs 1/6 th? Divide 5/6 th = 10/12 th among A and C! 5/12 A 1/6 B C C D 5/12 2/3 Notion of max-min fair: maximize min flow capacity (but not more than it needs)

29 Excursion: Fairness (2) Important concept: max-min fairness Max-Min Fairness A max-min fair scheduler maximizes the minimum rate of any data flow.... ignoring the flows which are at max demand already! Algorithm: Try to increase minimal rate (maybe up to demand), then increase 2nd smallest rate, etc. Stefan Schmid - 29

30 Excursion: Fairness (3) Max-min: can only increase one rate if there is no lower rate which would decrease Is FIFO max-min fair? No, flows arriving at higher rate get larger share... Is Round Robin max-min fair? Normally yes. Max-min approach allows to exploit bandwidth not used by some flows for other flows! Stefan Schmid - 30

31 Excursion: Fairness (4) Centralized algorithm for network: Max-Min Algorithm (for Network) 1. Start with all rates equal to 0 2. Grow all rates together at the same pace, until one or several link capacity limits are hit. The rates for the sources that use these links are not increased any more. 3. Continue increasing the rates for other sources. (All the sources that are stopped have a bottleneck link.) 4. The algorithm continues until it is not possible to increase. When the algorithm terminates, all sources have been stopped at some time and thus have a bottleneck link. Stefan Schmid - 31

32 Bits/second Policing Traffic Goal and reason: Limit traffic to not exceed declared parameters such as: Peak rate Average rate Burst size? Traffic varies (action scene, love scene, ): Can only guarantee service if not more than planned (= agreed) arrives! Otherwise: drop, shape, etc. Three commonly-used criteria: (Long term) Average Rate: how many pkts can be sent per unit time (in the long run) Time crucial question: what is interval length: 100 packets per sec or 6000 packets per min have same average! But latter is more flexible (can send 6000 in one sec!) Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; ppm peak rate (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle) Stefan Schmid - 32

33 Policing: Leaky Bucket Algorithm Used to police arrival rate + burst size of a packet flow(s)! Allows for irregular arrivals within certain bounds. Policing done by a leaky bucket that only forwards what fits the bucket. Simple policing algorithm with analogy to water bucket: traffic arrives accept packets as long as there is no overflow... (otherwise e.g., drop) water poured irregularly leaky bucket water drains at a constant rate Bucket depth corresponds to maximum allowable burst arrival Leak rate corresponds to long-term rate 1 packet per unit time (assume constant-length packet) Stefan Schmid - 33

34 Policing: Leaky Bucket Algorithm traffic arrives accept packets as long as there is no overflow... water poured irregularly leaky bucket water drains at a constant rate Leak rate corresponds to long-term rate Bucket depth corresponds to maximum allowable burst arrival 1 packet per unit time (assume constant-length packet) Let X = bucket content at last conforming packet arrival Let t a = last conforming packet arrival time Let b = size of leaky bucket Let L = leaky bucket threshold Stefan Schmid - 34

35 Leaky Bucket: Visualization Leaky bucket policy defines arrival curve with two parameters: burst b # arrived bits rate r Basically, traffic conforms to leaky bucket arrial curve if accumulated traffic is always below LB curve attached at all possible times t! time Remark: If network component provides a similar so-balled service curve, we can compute maximal delays, queue sizes, etc. analytically! (Network Calculus) Stefan Schmid - 35

36 Scheduling vs Policing vs Shaping Sometimes, one differs between shaping and policing: Traffic shaping (delay packets in queue to conform: may lead to losses at end of queue) Traffic policing (explicit dropping&marking) Which packets are chosen determined by scheduling Wikipedia Stefan Schmid - 36

37 Leaky Bucket Policing: Algorithm Arrival of a packet at time t a size of bucket is reduced by the time that passed since last accepted packet! current bucket size X = X - (t a - LCT) inter arrival time Yes X < 0? empty Assume: 1. depletion rate: one unit 2. I = increment per arrival 3. L = bucket threshold 4. b = L+I: bucket size Nonconforming packet non-empty No Yes X > L? X = 0 1. increase bucket by packet (only after decision!) 2. record that packet was accepted! no space in bucket No how full is leaky bucket? X = X + I LCT = t a conforming packet X = value of the leaky bucket counter X = auxiliary variable LCT = last conformance time arrival time of last packet that was accepted Stefan Schmid - 37

38 Leaky Bucket Example I = 4 L = 6 Nonconforming Packet arrival bucket size / depth L+I bucket content L X>L, i.e., X+I>L+I=b X>L Time I * * * * * * * * * Time Non-conforming packets not allowed into bucket and hence not included in calculations! Stefan Schmid - 38

39 Real Policing Mechanisms What do you think? Priorities, WFQ, etc.? Combine token bucket policing on arriving traffic plus WFQ multiplexing to provide guaranteed upper bound on delay, i.e., QoS guarantee! (e.g., Intserv/ DiffServ) arriving traffic token rate, r Make sure each source does not send more than in contract, then add to queue and schedule fair. bucket/burst size, b WFQ per-flow rate, R D = b/r max Gives max delay guarantees! As long as you conform to leaky bucket, there are at most b bits served before you! Stefan Schmid - 39

40 Admission Control: Example So far: how to police a single flow? Now: how many / which flows to accept? Users watch either one of two movies Star Wars (with the declared parameters) Amount of newly arrived data in time period [s,t]. Two arrival curves: (1) for peak rate, (2) for leaky bucket. E.g., a T-Spec of RSVP! Silence of the Lambs (with the declared parameters) Example: How many users can be admitted for each movie at a C=100Mbps link such that the delay for each user/movie is less than d=200ms? SW SOTL C=100Mbps Stefan Schmid - 40

41 The Impact of Admission Control In case of peak rate admission control? Always ensures peak rates: provides hard guarantees The formula: For (dual) leaky-bucket admission control? Ensures leaky bucket: provides hard guarantees The formula: Statistical admission control Provides soft-guarantees, e.g., (more complicated: no formula / algorithm here...) Average rate admission control In worst case, both streams come at peak rate all the time, can allow at most so many movies beforehand! Rates must be lower than bandwidth (queues empty), and delay must hold even under bursts (fill queue)! Only qualitative guarantees (e.g., ignore bursts, delay is always finite if they don t add up) The formula: Stefan Schmid - 41

42 Admission Control: Numerical Example Admission control impacts the total number of allowed users over 100Mbps channel! Only lambs at avg rate 1Mbps! The harder the constraints, the better the guarantees but the less admitted flows... (Worst peak rate, then LB, then probabilistic, then AVG) Multiplexing gain: 99% guarantee already gives much better utilization! Only lambs at peak rate 4Mbps! N1*2 < 100 N1*0.7/100 < 0.2 => N1 = Only stars at avg rate 2Mbps! Stefan Schmid - 42

43 General Model of Class-based Link Scheduling Scheduling in classes (=> queues!) - recall: classify to prioritize and isolate! - recall: priority scheduling, weighted fair queuing, etc. estimator class 1 class 2 classifier class 3 class 4 scheduler Stefan Schmid - 43

44 Link Sharing Among Classes The question: how to share a link among classes of packets in times of overload? Goals? Isolation principle: isolation among classes Efficiency principle: sharing between classes when link not fully used Among flows or between entities : link link flow1 flow2 flow3 NSF ARPA DOE Stefan Schmid - 44

45 Link Scheduling Framework Each class guaranteed some share (fraction) of bandwidth (over suitable time interval) if needed Use it or lose it: unused bandwidth should be used by others who can use it Concepts: Under-limit class: used less than guaranteed share Over-limit class: used more than guaranteed share; not a bad thing if not needed by others! At-limit class Unsatisfied class: has a persistent backlog and is under limit Satisfied: not unsatisfied Note: an under-limit class can be because it does not need more at the moment! (An over-limit class is never unhappy...) Stefan Schmid - 45

46 Example of a Scheduling Hierarchy link 50% 40% 10% Agency A Agency B Agency C ftp http smtp IP ATM rt nrt 30% 10% 10% 25% 15% 9% 1% Classes may be divided into subclasses, which can then further divide class bandwidth (guaranteed share of link) according to link scheduling guidelines! Stefan Schmid - 46

47 Simple Link Scheduling Guidelines A good regulation guideline for hierarchies? A class can continue unregulated if one of the following holds: the class is not overlimit the class has a not-overlimit ancestor at some level i, and there are no unsatisfied classes in Agency A link sharing structure at levels lower than i ( sisters ) link Agency B Agency C ftp http smtp IP ATM rt nrt Note: If a class is overlimit and all its ancestors too, also link (=root!) is overlimit => definitely regulate Note: if there exists such a no-overlimit ancestor and all lower happy => locally solved, no regulation! Stefan Schmid - 47

48 Example 1 link legend under limit at limit A B over limit satisfied unsatisfied backlog A1 A2 B1 B2 Q: which classes need to be regulated? A1? A? A2? None: Only A1 is over-limit, but his sister is happy being under-limit! (Classes which are not over-limit must never be regulated.) Stefan Schmid - 48

49 Example 2 link legend under limit at limit A B over limit satisfied unsatisfied backlog A1 A2 B1 B2 Q: which classes need to be regulated? A1? B2? B1? B? A1: no! Ancestor A is not overlimit and only has happy descendants => locally solved! B1: B s daughter B2 not satisfied as it is under-limit involuntarily (B1 should be throttled)!

50 Example 3 link legend under limit at limit over limit satisfied unsatisfied backlog A1 A2 B1 B2 Q: which classes need to be regulated? A? B1? Root?! A: is over-limit and e.g. sister is not happy; A1: is over-limit and only ancestor (link) that is not over-limit has unhappy descendant. Stefan Schmid - 50

51 Example 4 legend underlimit because overlimit sister => unhappy link under limit at limit over limit satisfied unsatisfied backlog A1 A2 B1 B2 Q: which classes need to be regulated? A2? B1? B? A2: No, not-overlimit ancestor (A) has happy descendants B1: Yes, only not-overlimit ancestor (link) has unhappy descendant A B: Yes, for same reason (maybe ok once B1 regulated, try first?) Stefan Schmid - 51

52 Take-Aways: Link Sharing Timescales over which persistent backlog and under/over limit defined are crucial E.g., yields different allowed burst magnitudes,... Too small not good either: complicated, too restrictive,... Aggregate level to which policy applies matters more specific => more state, less scalable Need rational basis for determining who is available to be scheduled in a multi-class, multi-objective system (elegantly) E.g., scheduling should ensure fairness Devil is in the details E.g., make sure it cannot be exploited... (e.g., by just using many parallel flows) Stefan Schmid - 52

53 QoS in the Internet: IETF Integrated Services (Intserv) Intserv = Architecture for providing QoS guarantees in IP networks for individual application sessions Resource reservation: routers maintain state info of allocated resources Admission control: admit/deny new call setup requests Question: Can newly arriving flow be admitted with performance guarantees while not violated QoS guarantees made to already admitted flows? Stefan Schmid - 53

54 Call Admission Arriving session must: declare its QoS requirement R-spec: defines the QoS being requested characterize traffic it will send into network T-spec: defines traffic characteristics signaling protocol needed to carry R-spec and T-spec to routers (where reservation is required) We know a protocol to achieve this! Namely...? RSVP Stefan Schmid - 54

55 Intserv QoS: Service Models [rfc2211, rfc 2212] Guaranteed service: worst case traffic arrival: leaky-bucket-policed source simple (mathematically provable) bound on delay per-flow [Parekh 1992, Cruz 1988] Controlled load service: "a quality of service closely approximating the QoS that the same flow would receive from an unloaded network element." arriving traffic token rate, r bucket size, b WFQ per-flow rate, R If R>r, only the burst can be in queue! D = b/r max Stefan Schmid - 55

56 Intserv: Reservation requires state Install per flow state along path between receiver and sender Sender Receiver Stefan Schmid - 56

57 Recall: RSVP Signaling protocol for establishing per flow (soft) state Carry resource requests from hosts to routers reservation message Collect needed information from routers to hosts E.g., about new servers (multicast semantic) At each hop Consult admission control and policy module Set up admission state or inform the requester of failure Decouples routing from reservation (relies on routing) Stefan Schmid - 57

58 Intserv: Flow based Flow based: per-flow classification E.g., can also choose subset of senders rather than all in multicast group Sender Receiver Stefan Schmid - 58

59 Intserv Example: Data Path per-flow buffer management Sender Receiver Stefan Schmid - 59

60 Intserv Example per-flow scheduling Sender Receiver Stefan Schmid - 60

61 Data Plane Control Plane How Things Fit Together Routing Messages Routing RSVP RSVP messages Admission Control Forwarding Table Per Flow QoS Table Data In Route Lookup Classifier Scheduler Data Out RSVP = only signaling specs Stefan Schmid - 61

62 Data Plane Control Plane How Things Fit Together Routing Messages Routing RSVP RSVP messages Admission Control Forwarding Table Per Flow QoS Table Data In Route Lookup Classifier Scheduler Data Out RSVP = only signaling specs Stefan Schmid - 62

63 QoS in the Internet: Class-based DiffServ DiffServ: qualitative service classes relative service distinction: Platinum, Gold, Silver marking of packets and per-hop behavior (PHB) scalability: simple functions in network core, relatively complex functions at edge routers (or hosts) signaling, maintaining per-flow router state difficult with large number of flows backbone router s of flows! don t define service classes, provide functional components to build service classes Less guarantees and simpler than Intserv? Stefan Schmid - 63

64 DiffServ Architecture Edge router: per-flow traffic management marks packets as in-profile and out-profile users may have agreed to a traffic profile Core router: per class traffic management buffering and scheduling based on marking at edge preference given to in-profile packets no need to consider sourcedestination pairs or so! principle: per-hop behavior (PHB) b r marking scheduling. Stefan Schmid - 64

65 Edge-router Packet Marking Leaky bucket profile: pre-negotiated rate A, bucket size B Packet marking at edge based on per-flow profile Rate A B User packets Possible usage of marking: Class-based marking: packets of different classes marked differently Intra-class marking: conforming portion of flow marked differently than non-conforming one (not thrown away!) Stefan Schmid - 65

66 Classification and Conditioning Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6 6 bits used for Differentiated Service Code Point (DSCP) and determine per-hop-behavior (PHB) that the packet will receive 2 bits are currently unused Stefan Schmid - 66

67 Overview Classification and Conditioning (on Edge) May be desirable to limit traffic injection rate of some class (even throw away= police/shape!): user declares traffic profile (e.g., rate, burst size) traffic metered, shaped if non-conforming Stefan Schmid - 67

68 In Core: DiffServ Hop Forwarding (PHB) PHB result in a different observable (measurable) forwarding performance behavior PHB does not specify what mechanisms to use to ensure required PHB performance behavior Examples: Class A gets x% of outgoing link bandwidth over time intervals of a specified length Class A packets leave first before packets from class B (strict priority => starvation?) Stefan Schmid - 68

69 Forwarding (PHB) PHBs being developed: Expedited Forwarding: pkt departure rate of a class equals or exceeds specified rate logical link with a minimum guaranteed rate Assured Forwarding: 4 classes of traffic more complex each guaranteed minimum amount of bandwidth each with three drop preference partitions DiffServ technically possible, but economical and legal challenges (inter-isp agreements difficult) also administrative problems (metering, whose fault,...) queuing only small fraction of end-to-end delay today (premium user may not notice difference!) but DiffServe can be a way to make money... will virtualization help (provide incentives by contracts / automatization)? Stefan Schmid - 69

70 Architecture: The Big Picture Stefan Schmid - 70

71 Architecture: The Big Picture Goals: identify, study principles that can guide network architecture bigger issues than specific protocols or implementation tricks synthesis: the really big picture Overview: Internet design principles rethinking the Internet design principles: original goals and now? telephone network architecture packet-switching versus circuit-switching revisited Where to put which functionality (layer and network)? And how many layers? Stefan Schmid - 71

72 Key questions How to decompose the complex system functionality into protocol layers? Which functions placed where in network, at which layers? Advantage of high layers? (Knowledge of what?) Advantage of low layers? (Knowledge of what?) Can a function be placed at multiple levels? Answer these questions in context of Internet, telephone net Stefan Schmid - 72

73 Common View of the Telco Network brain (smart) brick (dumb telephone) lock (you can t get in) Stefan Schmid - 73

74 Common View of the Telco Network Telephone network = relatively specific application. Telephone network has all the functionality / logics in core! (See also signaling lecture: DNS / 0800 system etc.) brain (smart) brick (dumb telephone) lock (you can t get in) Stefan Schmid - 74

75 Common View of the IP Network Internet: simply transport network, routers simple, logic in application = on end-hosts! Why? Costly, complicated, if more then only for performance? => end-to-end argument! Stefan Schmid - 75

76 Internet End-to-End Argument functions placed at the lower levels may be redundant or of little value when compared to the cost of providing them at the lower level sometimes an incomplete version of the function provided by the communication system (lower levels) may be useful as a performance enhancement (e.g., per-link retransmissions; cannot fully make e2e error check here!) This leads to a philosophy diametrically opposite to the telephone world of dumb end-systems (the telephone) and intelligent networks. Difference telephone vs Internet? Internet: many apps, not just voice, data-services with different requirements,? Stefan Schmid - 76

77 Example: Reliable File Transfer Host A Host B Appl. Appl. OS OK OS Solution 1: make each step reliable, and then concatenate them Solution 2: each step unreliable: end-to-end check and retry What is better? E.g., peer-to-peer file download? Stefan Schmid - 77

78 Discussion Solution 1 not good enough! what happens if the sender or/and receiver misbehave / don t verify? Send bogus data? so receiver has to do check anyway! doing it at lower layers too is then superfluous Any functionality can be entirely implemented at application layer; no need for reliability from lower layers! Stefan Schmid - 78

79 Discussion Q: Is there any reason to implement reliability at lower layers? A: Yes, but only to improve performance Example: assume high error rate in network reliable communication service at data link layer might help (why)? Fast detection /recovery of errors Performance: What works better at high layers, what works better at low layers? Stefan Schmid - 79

80 Trade-offs Application has more information about the data and semantics of required service (e.g., can check only at the end of each data unit: hash value over entire file?) Lower layer has more information about constraints in data transmission (e.g., packet size, error rate over a wireless link) Note: these trade-offs are a direct result of layering! (=> Does it make sense to reveal some infos from lower layers? Cross-layer design ) Stefan Schmid - 80

81 Internet & End-to-End Argument Network layer provides one simple service: best effort datagram (packet) delivery Transport layer at network edge (TCP) provides end-end error control performance enhancement used by many applications (which could provide their own error control) All other functionality all application layer functionality network services like DNS implemented at application level Stefan Schmid - 81

82 Internet & End-to-End Argument (1) Discussion: congestion control, flow control: why at transport, rather than link or application layers? Claim: common functions should migrate down the stack Everyone shares same implementation: no need to redo it (reduces bugs, less work, etc ) Knowing everyone is doing the same thing, can help Congestion control too important to leave up to application/user: true but hard to police in the network! TCP is outside the network; compliance is optional We do this for fairness (but realize that people could cheat) Why not at link layer? Then too late? Stefan Schmid - 82

83 Internet & End-to-End Argument (2) Why flow control in TCP, not (just) in app? Add functionality where resources are shared! Flow control is a problem of the device not of the application Shared TCP buffers at receiver mean want to control flow at TCP level (otherwise unfairness) Sharing resources is an important reason to push controlling functionality to point at which resources are shared Corollary: Do active queue management (e.g., RED) in network Share queues in a smarter fashion: functionality at queue Question: how much does careful controlled sharing buy you? Stefan Schmid - 83

84 E2E Argument: Interpretations One interpretation: A function can only be completely and correctly implemented with the knowledge and help of the applications standing at the communication endpoints (who else knows what app needs?!) Another: (more precise ) a system (or subsystem level) should consider only functions that can be completely and correctly implemented within it. Alternative interpretation: (also correct ) Think twice before implementing a functionality that you believe that is useful to an application at a lower layer If the application can implement a functionality correctly, implement it a lower layer only as a performance enhancement Stefan Schmid - 84

85 End-to-End Argument: Critical Issues end-to-end principle emphasizes: function placement correctness, completeness overall system costs (less redundant ) Philosophy: if application can do it, don t do it at a lower layer -- application best knows what it needs add functionality in lower layers iff (1) used by and improves performances of many applications, (2) does not hurt other applications allows cost-performance tradeoff Success story: Internet Stefan Schmid - 85

86 End-to-End Argument: Discussion End-end argument emphasizes correctness & completeness, not complexity: does complexity at edges result in a simpler architecture? evolvability, ease of introduction of new functionality in network?: easier/cheaper to add new edge applications than change routers? technology penetration: simple network layer makes it easier for IP to spread / get adopted everywhere (whereas complex functions would spread less) Stefan Schmid - 86

87 Internet Design Philosophy (Clark 88) In order of importance: 0 Connect existing networks initially ARPANET and ARPA packet radio network 1. Survivability - ensure communication service even with network and router failures 2. Support multiple types of services / applications 3. Must accommodate a variety of networks 4. Allow distributed management 5. Allow host attachment with a low level of effort 6. Be cost effective 7. Allow resource accountability (poor in today s Internet) Different ordering of priorities would make a different architecture! (Where is performance?) Grade it! How well solved? Stefan Schmid - 87

88 1. Survivability Continue to operate even in the presence of network failures (e.g., link and router failures) as long as network is not partitioned, two endpoints should be able to communicate any other failure (excepting network partition) should be transparent to endpoints Decision: maintain e-e transport state only at end-points eliminate the problem of handling state inconsistency and performing state restoration when router fails: routers only have to worry about routes! Internet: stateless network architecture No notion of a session/call at network layer (simple, fix!) How well is goal achieved? And why not? Grade: A- because convergence times are relatively slow BGP takes minutes to coverge IS-IS OSPF take ~ 10 seconds Stefan Schmid - 88

89 2. Types of Services add UDP to TCP to better support other apps Initially only TCP (together with IP!) e.g., real-time applications arguably main reason for separating TCP, IP datagram abstraction: lower common denominator on which other services can be built service differentiation was considered (remember ToS?), but this has never happened on the large scale (Why?) A- proven to allow lots of applications to be invented and flourish (except MM, but maybe that s not a transport service issue) Stefan Schmid - 89

90 3. Variety of Networks Very successful (why?) because the minimalist service; it requires from underlying network only to deliver a packet with a reasonable probability of success does not require: reliability in-order delivery The mantra: IP over everything Then: ARPANET, X.25, DARPA satellite network.. Now: ATM, SONET, WDM A: can t name a link layer technology that IP doesn t run over (carrier pigeon RFC) Stefan Schmid - 90

91 Other Goals Allow distributed management Administrative autonomy: IP interconnects networks each network can be managed by a different organization different organizations need to interact only at the boundaries but this model complicates routing A for implementation, B for concept (disagreement) Cost effective sources of inefficiency header overhead retransmissions routing but optimal performance never been top priority A Stefan Schmid - 91

92 Other Goals (Cont) Low cost of attaching a new host not a strong point intelligence is in hosts (e.g., telephone vs. computer) bad implementations or malicious users can produce considerably harm (remember fate-sharing?) C: but things are improving with dhcp, autocofigurations. Looks like a higher grade in future. Accountability Internet gets an F Stefan Schmid - 92

93 What About the Future? Datagram not the best abstraction for: resource management, accountability, QoS new abstraction: flow (see IPv6, OpenFlow, ) but no one knows what a flow is routers require to maintain per-flow state state management: recovering lost state is hard => first proposals of soft state! soft-state: end-hosts responsible to maintain the state in network Stefan Schmid - 93

94 Summary: Internet Architecture packet-switched datagram network IP is the glue (network layer overlay) IP hourglass architecture all hosts and routers run IP stateless architecture no per flow state inside network Where is innovation possible? TCP UDP IP Satellite Ethernet ATM IP hourglass Stefan Schmid - 94

95 Summary: Minimalist Approach Dumb network IP provide minimal functionalities to support connectivity addressing, forwarding, routing Smart end system transport layer or application performs more sophisticated functionalities flow control, error control, congestion control Advantages accommodate heterogeneous technologies (Ethernet, modem, satellite, wireless) support diverse applications (telnet, ftp, Web, X windows) decentralized network administration Stefan Schmid - 95

96 But that was yesterday. what about tomorrow? Stefan Schmid - 96

97 Rethinking Internet Design What s changed? operation in untrustworthy world endpoints can be malicious! (But they have functionality ) if endpoint not trustworthy, but want trustworthy network -> more mechanisms in network core more demanding applications end-end best effort service not enough new service models in network (Intserv, diffserv)? new application-level service architectures built on top of network core (e.g., CDN, p2p)? Efficient?? Stefan Schmid - 97

98 Rethinking Internet Design What s changed? ISP service differentiation ISP doing more (than other ISPs) in core is competitive advantage => innovative services Rise of third party involvement interposed between endpoints (even against will) e.g., Chinese gov t, US recording industry less sophisticated users All shift away from end-end! Stefan Schmid - 98

99 What s at stake? At issue is the conventional understanding of the`internet philosophy freedom of action user empowerment end-user responsibility for actions taken lack of control in the net that limit or regulate what users can do (firewalls, service differentiation, IDS ) The end-end argument fostered that philosophy because they enable the freedom to innovate, install new software at will, and run applications of the users choice [Blumenthal and Clark, 2001] Stefan Schmid - 99

100 Technical response to changes Trust: emerging distinction between what is in network (us, trusted) and what is not (them, untrusted). ingress filtering emergence of Internet UNI (user network interface, as in ATM)? Modify endpoints Harden endpoints against attack Endpoints do content filtering: Net-nanny CDN, ASPs (Active Server Pages): rise of structured, distributed applications in response to inability to send content (e.g., multimedia, high bw) at high quality ( middleboxes, caches ) Stefan Schmid - 100

101 Technical response to changes Add functions to the network core: filtering firewalls application-level firewalls NAT boxes active networking all operate within network, making use of applicationlevel information (!= end-to-end ) If addresses have meaning to applications, NAT must understand that meaning Stefan Schmid - 101

102 Firewalls Firewall Isolates organization s internal net from larger Internet, allowing some packets to pass, blocking others. administered network public Internet firewall Stefan Schmid - 102

103 Firewalls: Why? Prevent denial of service attacks: SYN flooding: attacker establishes many bogus TCP connections, no resources left for real connections. Prevent illegal modification/access of internal data. e.g., attacker replaces CIA s homepage with something else Allow only authorized access to inside network (set of authenticated users/hosts) Two types of firewalls: application-level packet-filtering Stefan Schmid - 103

104 Packet Filtering Should arriving packet be allowed in? Departing packet let out? internal network connected to Internet via router firewall router filters packet-by-packet, decision to forward/drop packet based on: source IP address, destination IP address TCP/UDP source and destination port numbers ICMP message type TCP SYN and ACK bits Stefan Schmid - 104

105 Packet Filtering Example 1: block incoming and outgoing datagrams with IP protocol field = 17 and with either source or dest port = 23. all incoming and outgoing UDP flows and telnet connections are blocked. Example 2: Block inbound TCP segments with ACK=0. prevents external clients from making TCP connections with internal clients, but allows internal clients to connect to outside. Stefan Schmid - 105

106 Application Gateways Filters packets on application data as well as on IP/TCP/UDP fields. Example: allow select internal users to telnet outside. host-to-gateway telnet session application gateway gateway-to-remote host telnet session router and filter 1. Require all telnet users to telnet through gateway. 2. For authorized users, gateway sets up telnet connection to dest host. Gateway relays data between 2 connections 3. Router filter blocks all telnet connections not originating from gateway. Stefan Schmid - 106

107 NAT: Network Address Translation Recall: Motivation: local network uses just one IP address as far as outside word is concerned: no need to be allocated range of addresses from ISP: - just one IP address is used for all devices can change addresses of devices in local network without notifying outside world can change ISP without changing addresses of devices in local network devices inside local net not explicitly addressable, visible by outside world (a security plus). Stefan Schmid - 107

108 NAT: Network Address Translation Implementation: NAT router must: outgoing datagrams: replace (source IP address, port #) of every outgoing datagram to (NAT IP address, new port #)... remote clients/servers will respond using (NAT IP address, new port #) as destination addr. remember (in NAT translation table) every (source IP address, port #) to (NAT IP address, new port #) translation pair incoming datagrams: replace (NAT IP address, new port #) in dest fields of every incoming datagram with corresponding (source IP address, port #) stored in NAT table Stefan Schmid - 108

109 NAT: Network Address Translation 2: NAT router changes datagram source addr from , 3345 to , 5001, updates table 2 NAT translation table WAN side addr LAN side addr , , 3345 S: , 5001 D: , S: , 3345 D: , : host sends datagram to , S: , 80 D: , : Reply arrives dest. address: , 5001 S: , 80 D: , : NAT router changes datagram dest addr from , 5001 to , 3345 Stefan Schmid - 109

110 NAT: Network Address Translation 16-bit port-number field: 60,000 simultaneous connections with a single LANside address! NAT is controversial: routers should only process up to layer 3 violates end-to-end argument NAT possibility must be taken into account by app designers, eg, P2P applications address shortage should instead be solved by IPv6 Stefan Schmid - 110

111 What is an Active Network? Depends on who you ask! Active services: application-level services exploiting position within the network to provide enhanced service CDN (content distribution networks) streaming media caches Capsule approach: packets carry programs (!), active node executes program when code-carrying packet arrives to active node code may determine what to do with packet may implement other service: e.g., network management, reliable multicast Stefan Schmid - 111

112 The capsule approach to active networks Network architecture that allows : application-customized code to be dynamically deployed in the network customized-code to be executed in controlled framework within network Similar to extensible operating systems (SPIN, Synthesize etc.) the new equation: Packet = Code + data sort of like postscript Stefan Schmid - 112

113 Capsules ANTS: active node transfer system (AN toolkit) ANTS Header IP header Version Type Previous Address Dep fields Payload Type Identifier for the forwarding routine to be executed (carries code by reference) Previous address Where to get the forwarding routine from if it is not available in the present node (Code Distribution) Dependent Fields Parameters for the forwarding code Payload Header + data of higher layers Stefan Schmid - 113

114 Active networking and End-End Arguments End-end principle: lower layers should have minimum functionality, but support widest variety of applications possible active networking: support all higher-level applications minimum common functionality: ability to execute code programmable versus pre-programmed low layer functionality Problems of ANs? Transparency? Stefan Schmid - 114

115 Active networking: transparency? Transparency: use of network by others not very visible (can more or less predict behavior of network) Active networking: transparency difficult constrain interactions among programmable entities in router (who knows wha they will try to do) like OS trying to constrain interaction among processes! Stefan Schmid - 115

116 KISS ( Keep it simple, silly! ) Success of LAN protocols, RISC architecture: KISS! Building complex functions into network optimizes network for small number of services, while substantially increasing cost for uses unknown at design time End-end argument does not oppose active networks per se but instead strongly suggests that enthusiasm for the benefits of optimizing current application needs by making the network more complex may be misplaced Make only simple functions for everyone there Stefan Schmid - 116

117 Epilogue: Will IP take over the world? Reasons for success of IP: reachability: reach every host, adapts topology when links fail (but robustness is more than this ) heterogeneity: single service abstraction (namely: best effort) regardless of physical link topology (generality but not necessarily simpler!) many other claimed (or commonly accepted) reasons for IP s success may not be true. let s take a closer look Stefan Schmid - 117

118 1. IP already dominates global communications! Business revenues: ISPs: 13B Broadcast TV: 29B Cable TV: 29.8B Radio broiadcast: 10.6B Phone industry: 268B Router/telco switch markets: Core router: 1.7B; edge routers: 2.4B SONET/SDH/WDM (optical networks): 28B, Telecom MSS (switching centers): 4.5B Stefan Schmid - 118

119 2. IP is more efficient! Statistical multiplexing versus circuit switching Statistical multiplexing much more efficient? Use links better? Link utilization: Avg. link utilization in Internet core: 3% to 30% Avg. utilization of Ethernet is currently 1% Avg. link utlization of long distance phone lines: 33% low IP link utilization: purposeful! predictability, stability, low delay, resilience to failure At low utilization, we forfeit benefits of statistical multiplexing! Stefan Schmid - 119

120 3. IP is more robust! Median IP network availability: downtime: 471 min/yr Avg. phone network downtime: 5 min/yr Why? Convergence time with link failures: BGP: 3 15 minutes SONET (synchronous optical network): 50 ms Why? Inconsistent routing state human misconfigurations in-band signaling (signaling and data share same network) routing computation complex Stefan Schmid - 120

121 4. IP is simpler! Intelligence at edge, simplicity in core Cisco IOS: 8M lines of code Telephone switch: 3M lines of code Linecard complexity: Router: 30M gates in ASICs, 1 CPU, 300M packet buffers Switch: 25% of gates, no CPU, no packet buffers 5. Support of real-time app s telephony over IP Not yet Stefan Schmid - 121

122 Discussion: Benefits of IP? IP supports many different types of data applications at a wide range of data rates Phone network: 1 or many services (voice, fax, touch-tone service, 800 numbers, teletype, hearing impaired services, lots of enhanced voice services, voic ) What about ATM (versus IP versus phone)? IP traffic, services more diverse (?). IP works at higher bandwidths (factually true for end applications, but cores are both high speed) Claim: IP supports short bursty connections better (implicit: less setup cost, less resources used not that important given utilization figures) IP has 1 rtt transaction times, phone network is at least 2 rtt (setup plus transaction) Stefan Schmid - 122

123 Detour: Implementation Principles Stefan Schmid - 123

124 Implementation Principles 3 classes of principles: System principles Improving efficiency while retaining modularity Making it go fast Cautionary tales: Think twice Stefan Schmid - 124

125 P1: Avoid obvious waste in common situations Obvious waste occurs when one does something twice, but (with thought) could do it only once (or never) user context operating system network interface buffers copy data from OS memory into user memory copy received data from network interface into OS memory pkts Stefan Schmid - 125

126 P1: Avoid obvious waste in common situations Obvious waste occurs when one does something twice, but (with thought) can do it only once (or never) user context pointer zero copy architecture Real-world example? Shopping? operating system pointer buffers network interface pointer pkts Stefan Schmid - 126

127 P2a: Use precomputation to shift computation in time Precompute quantities to save time at the point of use (or make use multiple times!) Precompute/initialize packet headers for packets in a connection Stored video data to be streamed to client: Store video data on disk prepackaged into IP packets. Finish filling out packet header when sending Real-world examples? Buy train ticket in advance / when not busy Holiday / travel requests: copy blueprints? Stefan Schmid - 127

128 P2b: Lazy evaluation: Only do work when it is needed Postpone work in hope not needed later, or more time later to do the work. Examples: Data arrives in wrong byte ordering (e.g., big-endian, on little endian machine): Only swap bytes when data actually read (savings if some bytes not read) Copy-on write: need second copy only once other user starts to change it ( copy virtually )! Before: both can read same page! address space A address space B address space A address space B Copy everything then use: byte-by-byte copy Copy-on-write: only copy bytes if user B writes (makes different from user A) Stefan Schmid - 128

129 P2b: Lazy evaluation: Only do work when it is needed Real world examples Students assigned readings of lecture notes: Lazy evaluation says do the reading only if it is on a homework! Stefan Schmid - 129

130 P2c: Batching to share overhead Process work (e.g., packet processing) in batches to amortize setup overhead Example: When processing data up (or down ) protocol stack, do multiple packets from connection at same time Real-world example: Sending a bunch of printouts to print room at once (only one trip over) Laundry you don t do it every day! Factory: Make a lot of one item at a time to only incur machine setup costs once Stefan Schmid - 130

131 P3a: Trading certainty for time If a deterministic approach is too slow, try a randomized approach Random access protocols (Ethernet) Statistical sampling of packet flows see upcoming lectures! Real-world examples? Sampling customers (surveying) Shopping schedule: Too much of a hassle to go shopping every sat morning so buy takeout for dinner Stefan Schmid - 131

132 P3b: Trading accuracy for time If computing the exact result is too slow, maybe an approximate solution will do Optimal solutions may be hard: Heuristics will do (e.g., optimal multicast routing is a Steiner tree problem) Faster compression using lossy compression Lossy compression: Decompression at receiver will not exactly recreate original signal Hot potato routing Real-world examples? Managing budget Quality/time tradeoff: Decreasing marginal returns: A 90% solution is good enough. Go one and do the next thing once you re 90% there Stefan Schmid - 132

133 P4: Leverage other system components Network protocols run in computing context: Lay out data structures and implement algorithms to enhance caching effects (reuse, make local memory accesses) Realize memory is organized in pages, lay out data structures to not cross page boundaries Trade memory for speed: Use precomputed lookup tables to get a value, rather than computing on fly each time Real-world examples? Precompute answers to questions at a press conference or talk ahead of time Stefan Schmid - 133

134 P5: Throw hardware at the problem Special-function hardware: CRC calculation, encryption Export processing functions off-board Network-interfaces Parallelize protocol functions Parallelized protocols (by layer, by connection, by packet) application transport network link physical thread per layer application transport network link physical thread per connection Stefan Schmid - 134

135 P6: Replace inefficient general-purpose routines P7: Avoid unnecessary generality One-size fits all can lead to inefficiencies By specializing, can gain performance (at cost of code bloat) TCP bundles congestion control and error control. What if you want congestion control but don t care about error control (e.g., real-time delivery of multimedia data) other example: ATM cell size (optimized for voice but used for lots of other types of traffic) but then why do we have only a small number of protocols/approaches at each layer? real-world examples help lines: treat you like a dummy, takes time to get specialized assistance standardized pants Stefan Schmid - 135

136 P8: Don t confuse specification with implementation Specifications indicate external effects/interaction of protocol. How protocol is implemented is up to designer Programming language specifications: In addition to specifying what, tend to suggest how. Real-world example: Recipe: 1. Cut onions 2. Cut potatoes 3. Put onion and potatoes into pot and boil Steps 1 and 2 can obviously be interchanged Stefan Schmid - 136

137 P9: Pass information, such as hints, across interfaces P10: Pass information in protocol headers Hints: Additional information that, if correct, can improve protocol performance/processing P10 example: Each arriving TCP segment contains the receiver-side memory location for the TCP connection record for that segment Receiver initially passes this information to sender, sender includes in all subsequent segments Receiver can find TCP connection records in future without lookup Real-world examples: Letters of recommendation Passing information to sales people (order #, phone #) before actual conversations allows them to prefetch all data Stefan Schmid - 137

138 P11: Optimize for the expected case Future system behavior often (but not always) follows expected pattern. Protocol processing sped up by assuming common case happens Example 1: Assume next arriving packet at receiver is from same connection as previous one Keep pointer to last accessed TCP connection record, check that one first before searching connection record list Example 2: Assume TCP segments arrive in order Can answer question: is this packet in order? faster than is this packet in my receiver window? Keep pointer to last byte copied into user s socket buffer, next inorder byte will follow that Stefan Schmid - 138

139 P11: Optimize for the expected case Real world examples: Service lines (e.g., help desks): Expect that user is novice (common case). If you know what you re doing, it takes longer to get help. Remote controls and user interfaces: common functions are fast and easy Stefan Schmid - 139

140 P12: Add or exploit state to gain speed Maintain state so that you don t have to compute something every time Example: Resource allocation Keep track of resources allocated so know what is free (alternative: go around to all resource users, compute what is being used. What not used is free ) Real world example: Checking account balance Stefan Schmid - 140

141 P13: Optimize degrees of freedom P14: Use special techniques with small sets of values P15: Use algorithmic techniques Stefan Schmid - 141

142 Some cautionary tales Q1: Is it worth improving performance? Does performance increase have high complexity cost? KISS: keep it simple silly E.g., router has so many protocols. Would routers be more robust if there were fewer protocols? Q2: Is this really a bottleneck? 80% of gains achievable by focusing on 20% of system Use profiling tools to see where time is spent Stefan Schmid - 142

143 Some cautionary tales Q3: Effect of change on rest of system? Does change increase performance in one place but slow down in other places? Q4: Does an initial analysis indicate potential significant improvement is possible? Is there room for improvement? How close to best possible performance? Think about (lower) bounds, solutions (e.g., oracle) with unachievable performance: if overestimated gain still small, don t do it Stefan Schmid - 143

144 Some cautionary tales Q5: Is it worth adding custom hardware to legacy system? Ride Moore s curve (doubling of processing speed every 18 months) or use specialized hardware? Q6: Can protocol changes be avoided? Rather than scrap existing protocol, tweak/rethink it to solve problem? Example: TCP s imminent demise predicted many times (e.g., TCP too slow for high-speed implementation) Stefan Schmid - 144

145 Some cautionary tales Q7: Does prototype confirm initial promise? Initial high-level analysis will miss details that could be important Some people will never be convinced without an implementation Q8: Will performance gains be lost if environment changes? Think about if improvements limited to small number of environments Example: Same-connection, in-order packet assumptions won t hold in busy server. Stefan Schmid - 145

146 Any missing cautionary tales? Make sure no one else has done it Corollary: If you have thought it up, it s likely that someone else has (or will soon) too Stress: complexity versus performance tradeoff: what really matters? Evaluate benefits under meaningful conditions Niklaus Wirth: Never hide a 10-fold overhead behind a simple interface! Stefan Schmid - 146

147 Radia Perlman: Folklore of Design Radia Perlman: mother of the Internet Contributions to spanning tree protocol (for network bridges) MIT, now with Sun Microsystems Entertaining summary of the memo, have a look: Stefan Schmid 147

148 Radia Perlman s Folklore of protocol design Collect various tricks and ''gotchas'' (wörtlich: erwischt! ) in protocol design ' Here are several ways to solve problem X'', with technical explanation of pros/cons Some real world examples We ll cover most, not all, tricks and gotchas Stefan Schmid 148

149 Simplicity vs. flexibility vs. optimality?? Is a more complex protocol reasonable? Is optimal important? (Approximation enough, e.g., dynamic anyway?) KISS: The simpler the protocol, the more likely it is to be successfully implemented and deployed. Charles Mingus Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that s creativity! Why are protocols overly complex? Design by committee (different stakeholders) Backward compatibility Flexibility: Heavyweight swiss army knife Unreasonable striving for optimality Underspecification Exotic/unneeded features Stefan Schmid 149

150 Make it Well-defined and Scalable! Know the problem you are trying to solve: Have at least one welldefined problem in mind Then: solve other problems without complicating solution? Think about scaling Think about what happens if you re successful: protocol is used by millions (prevent success desaster ) Think also about the other extreme: Does the protocol make sense in small situations as well? Stefan Schmid 150

151 Think about Overload/Failures! Operation above capacity Protocol should degrade gracefully in overload, at least detect overload and complain How does protocol break and die? Can t just die under overload! Stefan Schmid 151

152 Example: How to design identifiers? Identifiers: Protocols often contain a field identifying something, e.g., the protocol type. Two approaches: global or hierarchical Global: highly encoded universal (port) numbers: E.g., upper layer protocol # assigned by IANA (e.g., next header field in IP: 1=ICMP, 9=IGP, ): compact and interoperational, but central admin Hierarchical: general purpose object identifiers, as in ASN.1 (Abstract Syntax Notation One): hierarchical structure not compact (memory, BW, CPU, ), name clashes, but federalistic Stefan Schmid 152

153 SNMP naming Simple network management protocol (central protocol to monitor network elements) Question: How to name every possible standard object (protocol, data, more..) in every possible network standard?? Answer: ISO Object Identifier tree: Hierarchical naming of all objects Each branch point has name, number e.g., also used for X.509 public key certificates (objects therein...) ISO (0=ITU) ISO-ident. Org. US DoD Internet udpindatagrams UDP MIB2 management Stefan Schmid 153

154 OSI Object Identifier Tree Check out Stefan Schmid 154

155 Assigned Internet Protocol numbers From RFC 1700: Decimal Keyword Protocol References Reserved [JBP] 1 ICMP Internet Control Message [RFC792,JBP] 2 IGMP Internet Group Management [RFC1112,JBP] 3 GGP Gateway-to-Gateway [RFC823,MB] 4 IP IP in IP (encasulation) [JBP] 5 ST Stream [RFC1190,IEN119,JWF] 6 TCP Transmission Control [RFC793,JBP] 7 UCL UCL [PK] 8 EGP Exterior Gateway Protocol [RFC888,DLM1] 9 IGP any private interior gateway [JBP] 10 BBN-RCC-MON BBN RCC Monitoring [SGC] 11 NVP-II Network Voice Protocol [RFC741,SC3] 12 PUP PUP [PUP,XEROX] 13 ARGUS ARGUS [RWS4] 14 EMCON EMCON [BN7] 15 XNET Cross Net Debugger [IEN158,JFH2] Stefan Schmid 155

156 Example: Design for Common Case Optimize for common case Seen this before Nice example: IPV6 payload (packet) length field Payload length: only 2 bytes If packet longer: payload length = 0, but 4 byte length field found in IP options Designers chose against 4- byte header to optimize common case: 2 bytes are typically enough Of course, if no alternative avialable, better overestimate than underestimate! Stefan Schmid 156

157 Compatibility & Use of Parameters Forward compatibility Think about future changes, evolution Make fields large enough Reserve some spare bits Specify an options field that can be used/augmented later (see IP length discussion before!) Parameters: yes or no? Protocol parameters can be useful Designers can t determine reasonable values Tradeoffs exist: Leave parameter choice to users Parameters can be bad Users (often not well informed) will need to choose values Try to make values plugand-play! Stefan Schmid 157

158 Robustness: Notions Making systems robust : Many forms of robustness Immediately adapt to failure/change Self-stabilization: Eventually adapt to failure/change (example: self-stabilizing peer-to-peer overlays!) Byzantine robustness: Will work in spite of malicious users Maybe better to crash than degrade when problems occur: signal that problem exists Techniques for limited spread of figures Stefan Schmid 158

159 Missing folklore/advice? Stefan Schmid 159

160 Summary: Implementation principles Identify, study principles that can guide implementation of network protocols Common principles among many protocols Folklore of protocol design Synthesis: Big picture Architecture and implementation: Both more art than science Stefan Schmid 160

161 Designs for Scale Stefan Schmid 161

162 Designs for Scale How to deal with large numbers (millions) of entities in a system? IP devices in the Internet (0.5 billion) Users in P2P network (millions) More generally: Are there advantages to large scale? For every type of animal there is a most convenient size, and a large change in size inevitably carries with it a change of form. True for networks? Stefan Schmid 162

163 Dealing With Scale: Hierarchical Routing scale: with 500 million destinations: can t store all dest s in routing tables! routing table exchange would swamp links! administrative autonomy internet = network of networks each network admin may want to control routing in its own network Stefan Schmid 163

164 Hierarchical Routing aggregate routers into regions, autonomous systems (AS) routers in same AS run same routing protocol intra-as routing protocol routers in different AS can run different intra-as routing protocol gateway routers special routers in AS run intra-as routing protocol with all other routers in AS also responsible for routing to destinations outside AS run inter-as routing protocol with other gateway routers Stefan Schmid 164

165 Intra-AS and Inter-AS routing a C C.b b d A A.a a b A.c c B.a a B c b Gateways: perform inter-as routing amongst themselves perform intra-as routers with other routers in their AS inter-as, intra-as routing in gateway A.c network layer link layer physical layer Stefan Schmid 165

166 Intra-AS and Inter-AS routing a Host h1 C C.b b A.a Inter-AS routing between A and B A.c a d A b c Intra-AS routing within AS A B.a a B c b Host h2 Intra-AS routing within AS B Stefan Schmid 166

167 Dealing with scale: addressing Old-fashioned class-full addressing: class A B C 0 network host 10 network host 110 network host to to to D 1110 multicast address 32 bits to Stefan Schmid 167

168 IP addressing: CIDR Classful addressing: inefficient use of address space, address space exhaustion e.g., class B net allocated enough addresses for 65K hosts, even if only 2K hosts in that network CIDR: Classless InterDomain Routing network portion of address of arbitrary length address format: a.b.c.d/x, where x is # bits in network portion of address network part host part /23 Stefan Schmid 168

169 IP addresses: how to get one? Q: How does network get network part of IP addr? A: gets allocated portion of its provider ISP s address space ISP's block /20 Organization /23 Organization /23 Organization / Organization /23 Stefan Schmid 169

170 Hierarchical addressing: route aggregation Hierarchical addressing allows efficient advertisement of routing information: Organization /23 Organization /23 Organization /23 Organization /23. Fly-By-Night-ISP Send me anything with addresses beginning /20 Internet ISPs-R-Us Send me anything with addresses beginning /16 Stefan Schmid 170

171 Hierarchical IP addr: more specific routes ISPs-R-Us has a more specific route to Organization 1 Organization /23 Organization /23 Organization /23. Fly-By-Night-ISP Send me anything with addresses beginning /20 Internet Organization /23 ISPs-R-Us Send me anything with addresses beginning /16 or /23 Stefan Schmid 171

172 Hierarchical IP addr: more specific routes Multiple advertised routes could hold destination / /23 both hold always route to more specific destination (longest prefix match) Fly-By-Night-ISP ISPs-R-Us Send me anything with addresses beginning /20 Send me anything with addresses beginning /16 or /23 Internet Stefan Schmid 172

173 ATM addresses: E.164 numbering hierarchical 3 formats: (differentiated with Country Code) Geographical (Switzerland, North America, etc.) Country Code National Destination Code Subscriber Number ITU responsibility of each country or geographical area Global service (e.g., International Freephone Service, etc.) Country Code Global Subscriber Number ITU responsibility Network (BT, MCIWorldcom, etc) Country Code Identification Code Subscriber Number ITU responsibility responsibility of each network Stefan Schmid 173

174 Other Examples TCP window scale option: TCP throughput limited by windows size (congestion and receiver) Receiver window max 65k bytes: for bandwidth x delay products >65k Not enough e.g. for inter-satellite communication Solution without changing TCP: specify one byte shift in header option field: shift window size one to the left DNS anycast: Root name servers use anycast All have same (destination) address => requests will be routed to closest one (topologically) Decentralization! Stefan Schmid 174

175 Dealing with Scale Question: what are the advantages of large scale? take advantage of having to do similar things for others (caching) fault tolerance: large number of servers we have redundancy; multiple routes between sites Metcalfe s law: value of a network is proportional to square of number of things connected (bigger is better) law of large numbers: allocation of resources based on average usage rather than peak amortizing upgrade maintenance over a large population: popular network and services likely to be upgraded/improved denial of service: size/replication makes it harder to attack more generally, a system with replicated components is more survivable. Stefan Schmid 175

176 Dealing with Scale Discussion: For every type of animal there is a most convenient size, and a large change in size inevitably carries with it a change of form. Question: True for networks? What scales, what not? Examples? Ethernet doesn t scale up: geographical distance, speed of light delays degrade performance of random access protocols (geographic scaling). Maybe scale with # users in geographically narrow net if bandwidth scales with users. As number of communicants scales, need to change/improve manner in which to access communication channel Example: small number of students, versus 500-class lecture. Keeping bandwidth fixed as # users scales. PIM sparse versus PIM dense: push or pull in multicast? push systems work ok when small number of sender (PIM dense) pull is better with large number of senders Stefan Schmid 176

177 Dealing with Scale Discussion: For every type of animal there is a most convenient size, and a large change in size inevitably carries with it a change of form. Question: True for networks? Why? How so? Examples? routing: large number of users and optimal routes => requires lots of info to compute routes, etc... doesn t scale certain services become necessary when you get big name index/storage/translation: dns, phone books a single centralized site eventually breaks need replication or other form of distribution as network gets bigger flooding breaks use limited flooding, caching (Gnutella) switched vs. routed networks change from layer 2 switched networks to layer 3 routed networks as # users gets bigger Stefan Schmid 177

178 End of Design Principles! Goals review: different backgrounds framework for covering advanced topics material that is timely, timeless: hot now but also long shelf life synthesis: deeper understanding; see the forest for the trees Stefan Schmid 178

179 Randomization Stefan Schmid 179

180 Randomization Randomization used in many protocols Why? break symmetries (e.g., among symmetric elements) desynchronize (e.g., when only one answer is needed) avoid worst-cases (remember QuickSort?)... or just make protocol simpler!! we ll study examples: Shared medium/bus access: Ethernet multiple access protocol router (de)synchronization switch scheduling Stefan Schmid 180

181 Ethernet Single shared broadcast channel 2+ simultaneous transmissions by nodes: interference only one node can send successfully at a time multiple access protocol: distributed algorithm that determines how nodes share channel, i.e., determine when node can transmit Inspired by the ALOHANet of Hawaii (first radio network, connecting Hawaian islands...), quite efficient (close to 100% at low utilization) Initially star topology connected by hub, nowadays switch in center... Metcalfe s Ethernet sketch TAP: vampire tap, T- Stück, ( Spannungsmessung etc.) Transceiver: Transmitter and Receiver Stefan Schmid 181

182 Deterministic Algorithms How to share the medium using deterministic algorithms...? Time Division Multiplexing? But how to organize? What if someone has nothing to send? What if additional hosts are added and removed? Etc. Centrally controlled? Polling? Virtual Ring? (Pass token?) Etc. Randomized often simpler and more efficient! Stefan Schmid 182

183 Ethernet: uses CSMA/CD Carrier Sense Multiple Access / Collision Detection A: sense channel ( CS ), if idle then { transmit and monitor the channel; // asynchronous protocol! If detect another transmission ( CD ) then { abort and send jam signal; update # collisions; delay as required by exponential backoff algorithm; goto A } else {done with the frame; set collisions to zero} } else {wait until ongoing transmission is over and goto A} Stefan Schmid 183

184 Ethernet s CSMA/CD: Jam Signal Jam Signal: make sure all other transmitters are aware of collision (48 bits) Why?: A starts to send, at shortly before signal reaches B, B starts to send: A B B immediately notices collision and stops; but to make sure A notices the collision too and will also stop the transmission, a higher power signal is needed Etnernet limits spatial extension... (notice before finished!) Stefan Schmid 184

185 Ethernet s CSMA/CD: Backoff Exponential Backoff Algorithm: first collision for given packet: choose K randomly from {0,1}; delay is K x 512 bit transmission times after second collision: choose K randomly from {0,1,2,3}, {0,1,2,3,4,5,6,7}, etc. after ten or more collisions, choose K randomly from {0,1,2,3,4,,1023} (limited scale!) Stefan Schmid 185

186 Ethernet s use of randomization Resulting behavior: probability of retransmission attempt (equivalently: length of randomization interval) adapted to current load simple, load-adaptive, multiple access! more collisions heavier load (most likely), more nodes trying to send randomize retransmissions over longer time interval, to reduce collision probability Stefan Schmid 186

187 Ethernet Comments Upper bounding at 1023 = K limits max network size! Max spatial extension of Ethernet makes sure sender with lowest K value has a good chance to successfully send entire packet before next collision Could remember last value of K when we were successfull... rather, new packet is tried with minimal backoff again! (Analogy: TCP remembers last values of congestion window size) Q: why use binary backoff rather than something more sophisticated such as AIMD: simplicity Stefan Schmid 187

188 The bottom line Why does Ethernet use randomization? E.g., to desynchronize: A distributed (= each host runs the protocol independently ) adaptive algorithm to spread out load over time when there is contention for multiple access channel Stefan Schmid 188

189 Efficiency of Ethernet? Approximation formulas, e.g. Eff = 1/(1+5*prop/dur) where prop = max propagation time between two adapters dur = time to transmit packet of max size Intuition: If prop is very small, transmissions are stopped immediately when colliding, so efficient! If dur is very large, channel is used for a long time without collisions, which is efficient again (but fair?). Stefan Schmid 189

190 Excursion: What changes with wireless? Typical wireless networks : are not full-duplex (just one channel...) nodes cannot sense the medium during own transmissions (just one antenna...) no bounded propagation domain are multihop (hidden and exposed terminal problems): A B C Hidden terminal: C does not notice that B is currently receiving transmissions from A also => no remote carrier sense Exposed terminal: B sends A and C wants A B C to send to someone on the right: it waits because it hears B, but B would not reach the recipient of C, so actually C could send! => inefficient Stefan Schmid 190

191 Excursion: What changes with wireless? Typical wireless networks : are not full-duplex (just one channel...) nodes cannot sense the medium during own transmissions (just one antenna...) no bounded propagation domain are multihop (hidden and exposed terminal problems): A B C Hidden terminal: C does not notice that B is currently receiving transmissions from A also => no remote carrier sense Exposed terminal: B sends A and C wants A B C to send to someone on the right: it waits because it hears B, but B would not reach the recipient of C, so actually C could send! => inefficient Stefan Schmid 191

192 Randomize to avoid synchronization! Phenomenon: many apparently independent processes synchronize over time Classic example: 17th century (Huygens) Two pendulums synchronize if attached to same wall! Try putting two metronomes on the same floor... Similar phenomena: blinking of fireflies, road traffic and car kinetics (one car reduces speed: collective decrease in flow), TCP window increase/decrease cycles in presence of shared bottleneck gateway, client/server scenarios where server is busy, etc. Stefan Schmid 192

193 Youtube! Stefan Schmid 193

194 Fireflies... ( Glühwürmchen ) Stefan Schmid 194

195 «Routing messages can get synchronized over time!» Take-home messages: Emergent phenomenon: no synchronization up to a certain scale, and then fully synchronized! Can result in long delays... Randomization can help, but quite a lot is needed! Stefan Schmid 195

196 (de)synchronization of periodic routing updates Periodic losses observed in end-end Internet traffic at 90 sec intervals Ping messages to Harvard and MIT (1-sec intervals) Round trip times in figure: losses shown as negative RTT Why? IGRP routing updates: routers could not forward other packets while large routing updates were processed; similar phenomena with RIP... Found paths with 318sec/45sec/15sec spikes... Stefan Schmid 196

197 Router Updates A simplified model (for EGP, IGRP, RIP, etc.): Routers transmit routing messages at periodic intervals (ensures consistent tables even after losses) 1. A router prepares and sends its routing message. In the absence of incoming routing messages, this takes time Tc (= time to process an outgoing or incoming message) seconds. Other nodes receive this router s message after Td seconds. 2. If a router receives an incoming routing message while preparing its own outgoing routing message, it also processes the incoming routing message, which takes time another Tc seconds (for each such event). After Steps 1.+2., the router sets a timer Tp which expires after approx. between {Tp-Tr, Tp+Tr} seconds, where Tr describes the random fluctuation (e.g., OS overhead). When it expires, we go back to Step 1. Whenever a router receives a triggered update (e.g., link failure), we go directly to Step 1. without waiting for timer to expire. Stefan Schmid 197

198 Router Update Operation: time spent in state depends on msgs received from others (weak coupling between routers processing) timeout, or link fail update receive update from neighbor process (time: T C ) prepare own routing update (time: T C) <ready> send update (time: T d to arrive at dest) start_timer (uniform: T p +/- T r ) wait receive update from neighbor process Stefan Schmid 198

199 Router Synchronization Simulation: 20 routers broadcasting updates to each other x-axis: time y-axis: offsets By t=100,000 all router offsets are of at 120 and synchronized! Yields long delays... (20*Tc instead of Tc seconds!) synchronization or lack thereof depends on system parameters (e.g., crucially on network size according to the paper: emergent) Often a robust trend to or away from synchronization... Stefan Schmid 199

200 Details A s timer expires, begins to send message but before finishing, B s timer expires, A needs to process this also before resetting its timer, so this takes time 2*Tc. In next round A and B will start at similar time when B receives A s message early: become a cluster. However, also both intervals can become longer... (for Td=0) Blowup of previous graph Note expansion of computation phase increased period long interval Desynchronization due to some random event... short interval Stefan Schmid 200

201 Sync Coupled routers Example of spontaneous synchronization fireflies sleep cycle heart beat etc. Steven Strogatz. Sync, Hyperion Books, Stefan Schmid 201

202 Avoiding Synchronization? Enforce max time spent in prepare state Make things independent of external events (e.g., spec of RIP)? Problem: If initially sync, never desync... Choose random timer component, T r large receive update from neighbor process (time: T C ) prepare own routing update (time: T C) wait <ready> send update (time: T d to arrive) start_timer (uniform: T p +/- T r ) receive update from neighbor process Stefan Schmid 202

203 Router (de)synchronization Takeaway: Randomization to desynchronize routers! Our model was simplistic: ignores collisions, Ethernet retransmissions, etc. Stefan Schmid 203

204 Randomization in Reliable Multicast Reliable Multicast: how to transfer data reliably from source(s) to R receivers. Like in real life : all current RM error and congestion control approaches have an analogy in human-human communication Stefan Schmid 204

205 Scalability: Feedback Implosion Smart and scalable reliable MC? sender rcvrs... If all receivers ACK immediately upon reception, the sender has to process a large number of messages! Stefan Schmid 205

206 Reliable Mcast Thus, we can distinguish between two main types of multicasts: Sender-oriented multicast: how to implement? Pro and con? Receiver-oriented multicast: how to implement? Pro and con? What is better? Two sample implementations next... Stefan Schmid 206

207 ACK Sender Oriented Reliable Mcast Sender: mcasts all (re)transmissions selective repeat if loss (only lost packet, but Mcast to all again) timers for loss detection (positive) ACK table: for each packet list of who ACKed already pkt removed when ACKs are in Rcvr: ACKs received pkts burden: ACK lists, timer, ACK implosion,... Note: group membership important (sender needs to know ) How to do it reliably with less burden at server?! sender X receivers Without ACKs?! Stefan Schmid 207

208 (simple) Rcvr Oriented Reliable Mcast Sender: mcasts (re)transmissions selective repeat (but to all) responds to NAKs Problem: when stop buffering pkt? (sender does not know who is there and interested!) Rcvr: NAKs (unicast to sender) missing pkts (e.g., gap in seq numbers) timer to detect lost retransmission sender X NAK receivers Note: easy to allow joins/leaves: no list at sender Stefan Schmid 208

209 Receiver- vs Sender-oriented RM: Observations? (Dis)Advantages? Rcvr-oriented: shift recovery burden to rcvrs loss detection responsibility, timers scaling: protocol computational resources grow as R (# receivers) grows ( receivers scale, sender does not! ) weaker notion of group (no explicit lists at server ) also cool: receivers can transparently choose their own, individual reliability semantics! but when does sender release data rcvd by all? heartbeat needed to detect lost last pkt (receivers won t notice a lost last packet, no gap in seq numbers ) Stefan Schmid 209

210 Evaluation of Approaches Let s examine resource requirements! processing requirements expected time to process pkt at sender: X, E[X] at rcvr: Y, E[Y] mean value approach network requirements Stefan Schmid 210

211 Processing in Sender-Initiated Protocol For Mcast, sender must: Obtain data from higher layers (app) Construct packet Set timer Process every ACK for each packet and receiver Timer interrupts and context switches... If error: rebroadcast, set timer again... Stefan Schmid 211

212 Assumptions for Analysis one sender, R receivers computational load matters! independent errors (not true for spanning tree propagation!), p per rcvr lossless signaling (okay: short ACKs less likely to get lost, and sometimes get a better service ) M - total number of transmissions per packet: Prob that none of the m transmissions arrives at a given rcvr: p m, so it works with prob 1-p m ; prob that all rcvrs work: product... 1 m R, 1, P[ M m] p m m 1 E[M]= m P[M=m]: counting multiple times with P[M>m]! Stefan Schmid 212 E[ M ] 1 1 p m R

213 Analysis E.g.: Stefan Schmid 213

214 Sender vs Receiver: Simulation Metric - rcvr oriented thruput/sender oriented thruput One-to-Many Comparison p=0.01 p=0.05 p=0.10 p= Many-to-Many Comparison p=0.01 p= p= p= No. Receivers No. Receivers - sender is bottleneck (s. paper), so sender throughput = overall system throughput - much better throughput in receiver-oriented MC - especially for many receivers (scales better) and low error probability (hardly any NAKs ) - in many-to-many multicasts less Stefan Schmid 214

215 RM: Coping with Scale, Heterogeity How to do even better? Issues: avoid feedback implosion in reverse path avoid receiving unneeded data (retrans.) in forward path recover data quickly, avoid long repair times Techniques: feedback suppression local recovery: local retransmission

216 Feedback Suppression randomly delay NAKs listen to NAKs generated by others if no NAK for lost pkt when timer expires, multicast NAK widely used in RM tradeoffs reduces bandwidth, especially with correlated errors (e.g., along spaning tree) but: additional complexity at receivers (timers, etc), maybe higher delay sender X X Stefan Schmid 216

217 Feedback Suppression: Performance Gains Metric - suppression thruput/no suppression thruput One-to-Many Comparison p=0.01 p=0.05 p=0.10 p= Many-to-Many Comparison p=0.01 p=0.05 p=0.10 p= No. Receivers - If high errors helps more and scales almost linearly in number of receivers! - gains/loss depends on whether 1-many or many-many (receivers are also senders, additional complexity now matters, etc.) No. Receivers Stefan Schmid 217

218 Local Recovery in SRM Another idea: fix locally! Allow rcvr to recover lost pkt from nearby rcvr ask your neighbor : send localized NAK (repair request) multicast: randomize local repair transmission time to avoid too many replies orthogonal (complementary) to feedback suppression who to recover from? don t want repair request to go to everyone scoping: how to restrict how far request will travel: IP time-to-live field

219 Local Recovery: Example R2 detects lost pkt multicasts repair request limited scope not seen by R4 R1 and R3 have pkt R3 times out first and sends repair R3 R4 R1 R2 repair Stefan Schmid 219

220 Reliable multicast (SRM) Use of randomization avoid synchronizing all replies to reduce feedback implosion in local recovery, to reduce number of retransmissions of same message could scale the randomization interval to be load-adaptive Stefan Schmid 220

221 Sidenote: Multicast vs N Unicasts Multicast group concept preferable (e.g., IP multicast, indirection) to N unicasts (e.g., N TCP connections): no redundant transmissions over a link Challenges for (reliable) multicast: fate-sharing in unicast clear: either sender or receiver must detect and recover from errors (e.g., in TCP: sender); but in multicast receivers can come and go any time? smart round trip time estimate with heterogeneous recievers?? (in unicast clear...) congestion window size? => receiver-based often better... (e.g., IP multicast, RSVP) Stefan Schmid 221

222 Randomization in Switch Scheduling Two key router functions? run routing algorithms/protocol (RIP, OSPF, BGP) switching datagrams from incoming to outgoing link (our focus here)... and filtering (ACLs), buffering, scheduling,... Stefan Schmid 222

223 Input queueing with bufferless outputs N input ports, output ports each port has N per-output port queues why? virtual output queues prevent head-of-the-line blocking FIFO phenomenon matching problem: in each time slot each output port can receive at most one packet from among NxN input queues each input port (N queues) can forward at most one packet Input 1 switch fabric Output 1 Input N Output N scheduler Stefan Schmid 223

224 Remark: Head-of-Line Blocking Blocked because of same output only...: if the HOL packet of a certain buffer at the input cannot be switched to an output port because of contention, the rest of the packets in that buffer are blocked by that Head-of-Line packet, even if there is no contention at the destination output ports for those packets (according to literature: around 50% efficiency loss otherwise!) Stefan Schmid 224

225 Solving the assignment problem W ij : queue length (weight) of input i, queue j How to solve? Each port at most one packet out (and in) per time step: maximum weight matching solution takes O(N 3 ) that can deliver ~100% throughput Why weight important? For non-uniform traffic, delay, keep queue sizes balanced (heterogeneity, parallelism), is a good solution also in the near future (queue sizes change slowly) so no recomputation necessary,...? Can we do better? And why? (Scalability of backbone routers!) Stefan Schmid 225

226 Using randomization to optimize Key observations: 1. state of switch (input queue lengths) changes little from slot to slot good solution at t, is close to good solution at t+1 2. a new, randomly-chosen solution will sometimes be better solution at t+1 than solution used at t How to implement these ideas? Stefan Schmid 226

227 Using randomization to optimize Algorithm: t=0 choose any matching M(0) switch operates using M(0) for one slot for (t=1; ; t++) generate new solution M(t) if (M(t-1) better than M(t)) M(t) = M(t-1) switch operates using M(t) for one slot randomly generated solution better (so solution changes) t=0 t=1 t=2 t=3 t=4 t=5 t=6 Attention: example wrong, not really a matching! Stefan Schmid 227

228 Using randomization to optimize result [Tassiulas]: randomized algorithm achieves ~100% thoughput (i.e., as good as brute force, non-randomized O(N 3 ) optimization algorithm) e.g., see also follow-ups for better delay: Stefan Schmid 228

229 Randomization in Router Queue Management normally, packets dropped only when queue overflows Drop-tail queueing Why not good?! P 6 P 5 P 4 P 3 P 2 P 1 FCFS Scheduler ISP router Internet ISP router Stefan Schmid 229

230 The case against drop-tail queue management P 6 P 5 P 4 P 3 P 2 P 1 FCFS Scheduler large queues in routers are a bad thing : End-to-end latency dominated by length of queues at switches in network allowing queues to overflow is a bad thing connections transmitting at high rates can starve connections transmitting at low rates ( lockout phenomenon due to timing effects) connections can synchronize their response to congestion (multiple connections receive congestion feedback at the same time) Stefan Schmid 230

231 Idea: early random packet drop P 6 P 5 P 4 P 3 P 2 P 1 FCFS Scheduler When queue length exceeds some threshold, packets dropped with fixed probability early and probabilistic packet drop: flows see same loss rate a form of early packet drop and active queue management why this threshold and not always the same probability? So queue less full than before... Why not simply shorten the queue? We want accomodate bursty traffic if it happens! Only throttle long-term load... (If entire burst gets lost, global throttling back yields low link utilization!) Why random? Avoid sync, random sampling simple (no state per flow etc.!),... Problem: bursty traffic (burst arrives when queue is near full) can be overpenalized Why smooth transition? Avoid synchronization effects... But note: Providers may like full queues: good link utilization? Stefan Schmid 231

232 Random early detection (RED) packet drop Average queue length Max queue length Max threshold Min threshold Moving avg over time.. Drop probability Time Forced drop Probabilistic early drop No drop How to implement these ideas? How to prevent overpenalizing smoothly? Two factors: smooth average and smooth transition... use exponential average of queue length to determine when to drop avoid overly penalizing short-term bursts react to longer term trends tie drop prob. to weighted avg. queue length avoids over-reaction to mild overload conditions Stefan Schmid 232

233 Random early detection (RED) packet drop Average queue length Max queue length Max threshold Min threshold Drop probability Time Forced drop Probabilistic early drop No drop Drop probability 100% max p min max However, RED is not so Weighted Average popular... Why? Queue Length Stefan Schmid 233

234 RED: Why probabilistic drop? Advantages? provide gentle transition from no-drop to all-drop provide gentle early warning provide same loss rate to all sessions: with tail-drop, low-sending-rate sessions can be completely starved avoid synchronized loss bursts among sources avoid cycles of large-loss followed by no-transmission Purpose of queue: buffering of bursts, not long-term queueing... Stefan Schmid 234

235 Random early detection (RED) packet drop large number (5) of parameters: difficult to tune (at least for http traffic) Depends on # active data transfers, RTT distribution,... gains over drop-tail FCFS not that significant still not widely deployed E.g., a critical article: Stefan Schmid 235