Administration stuff This week conclude basics of networking. By the end of today, we would have reached limits of what people know about networking. Rest of quarter, we will cover papers that have been written in last 10 years, 90% last 5 yrs, 50% last two. This should encourage more discussion. Next week -- Janet leads class; Tom in Princeton. How to measure, think about measure, lie with graphs and catch people lying with graphs. Should class be more discussion-oriented? (Prompted by anon feedback) Tom: Have been rocketing through early work to get through it; has been less room for discussion. Also, this is the first grad nets class Tom's taught in a decade; been teaching lots of undergrads. Catch him if he falls back on lecture-style. Continuation of previous Class Congestion control -- well-trodden research area; hundreds of papers; no time for all. Q. What was the program committee's biggest objection to Kitabi's XCP paper (Conjecture)? A. It was not deployment issues. In fact, it was related work. Didn't reference ATM / give it due credit. Caused program committee and conference attendees to get hung up on how it was like ATM, and not the more important ways that it was different from ATM, and its control-systems framework for reasoning about its stability. Lesson: If you don't control the terms of the discussion, they'll misunderstand. Should've described ATM and how what it does is different. Q. What is ATM ? A. ATM is a circuit-switched network and not datagram-switched. Rate information in ATM-frame headers; each ATM router updates this rate information so the min of the rate requested in the header and the rate the router can/will provide. ATM doesn't specify how the router chooses that rate. Space of congestion solutions (mechanisms) Note : Space division can also be as "avoidance vs recovery" or "detect vs control". But we are looking at a different space division. Choices that we have : End host is responsible, (method used by TCP) + Chosen because it was easy -- can be done in SW, can be changed incrementally + (Aside: Remember Vegas; can't use it because it competes poorly w/ TCP) - Must rely on host's proper behavior. Based on trust. So security is an issue. * What measurements can you use? * Loss It is simple and the rest measurements are lesser noisy and more aggresive. * Jitter in RTT -or- jitter in packet (packet-pair measurement) -or- Packet delivery rate These could provide a simple solution to early congestion detection, but it is still not done because of competition. It's not advantageous to any given end host to implement early congestion detection, since it will just lose out to TCPs that don't do it. So, the network is the only place where early congestion detection and control can be. * Interesting TCP flaw for TCP/IP over local Ethernet (no intervening routers) Local ethernet never loses packets, so congestion window grows forever, even though rate gets limited eventually by the speed of the ethernet. (CWND size has max, but how big?) Also, because e-net is a bus protocol, collisions occur between data and ACKs. Network is responsible (eg. ATM, credits and penalty boxes) + ATM does rate control based on per-connection state. Number of states are proportional to number of connections. But per connection state allows good rate control. + ATM in credits work on hop-by-hop flow control (per-connection). They first, determine if there's space at the upstream router. There are separate queues per circuit. This allows per-circuit isolation. + Penalty box. These keep cache of big connections; preferentially drop big connections. So it is a win for smaller ones. - Need some enforcement strategy, otherwise fails. End host responsible, but the network helps (RED, XCP, ECN) - Problems with RED: Parameters are tough to set well. Also, it may sound pretty inexpensive, but there are still some operational costs. Also, it is not robust to regular traffic. - Even withou RED, synchronization tends not to happen. - Internet backbone is "outrageously" underutilized. High utilization leads to full queues and thus high latency. Since most traffic is web traffic, high latency drives people away, so it's advantageous to overprovision to keep latency down. Also, overprovisioning is not so much more expensive than provisioning just enough.High utilization is often the result of failovers. Host control with network incentives. We need to build economic models for this. Some Questions to answer Q. Is TCP fair ? What if two TCP connections share a bottleneck? A. A - \___[B][B][B][B][B][B]----- / B - Every time a packet leaves the queue, the same host that put the packet in is liable to reclaim that packet's slot, since every packet that leaves the queue will quickly prompt its sender to send again (by ACK clocking). So, if B dominates the queue at some point (eg. as shown), until B experiences a packet loss, it will probably continue to dominate the queue. Indeed, if B held the whole queue, A might be locked out for awhile. RED keeps the queue from being completely full, and so helps prevent this kind of network synchronization. TCP is fair over longer period of times, RED is fair over even small periods. Q. What happens to TCP if we increase buffering? A. Latency gets worse Q. Does that mean, we can decrease buffering as much as we want ? A. No, there would transient losses. We will not be able to fill the bottleneck. So under utilization. The aim is to get enough bandwidth to handle the networks bandwidth-delay product worth of packets. Q. What happens as we increase the numberof flows to infinity? A. End-to-end latency increases. The average CWnd goes less than one, which means that some flows are never getting through. We can analytically show that drop rate goes to 50%. Q. What if most connections are short (all flows less than 5 or 10 packets)? A. Losses have no impact on congestion, as there is no historesis between flows. End-to-end performance gets dominated by slow start (End-to-end performance dominated by (RTT x log N), where N is number of bytes being transferred). Losses have a big impact on end-to-end latency. The variance increases. Predictability goes down. RED tries to handle this issue, but as the second paper talks, this RED Doesn't help! Early notification to short connections just slows them down, without really affecting congestion. Q. What about a mix of big and little connections in TCP? A. There are lots of losses. Bandwidth is proportional to (loss rate)^(-0.5). So, if there's a moderate to high loss rate, it's advantageous to stripe big transfers across several connections. This increases slow-start slope. But, losses only affect the connections experiencing loss. So, for same loss rate, we need more bandwidth to get through. Bigger transfers can then compete better with small connections. But this is a disastrous solution. RED allows large connections and small connections to share better. Combine with penalty box to preferentially throttle back big connections to reduce latency for small ones. Question to think about ? Finally, which is better? Which will happen? Can we have some kind of economic control ? Is XCP easy to spoof? Can we hack TCP and find a aggregate-based congestion control across short flows ? Can we deploy RED or some variant? ( eg. modified penalty boxes)