Ledbat WG, Stanislav Shalunov Went through the charter - standardize congestion control mechanism Went through the history P2Pi in MIT to the two BoFs that resulted (ALTO and LEDBAT). TANA (precursor to LEDBAT) BoF in TSV and ALTO in APPS area. Charter background: TCP fills buffer in the head end of the congested bottleneck (router or cable/dsl modem). Buffer can be large. RTT in seconds => Everyone is delayed and interactive applications cannot work. Two work items: experimental congestion control mechanism and an info document that describes current practice and implications of using multiple connections in applications. Congestion control requirements: saturate the bottleneck keep delay low when no other traffic quickly yield to TCP add little to queuing delays included by TCP work w/ FIFO/drop-tail work w/ AQM, Diffserv, and ECN where available Initially experimental RFC; how our work applies to various existing tansports remains TBD. Multiple connections history: why apps open multiple connections? Many reasons. We need to describe how many connections there are and why apps should and should not open multiple connections, and describe what happens when you do so. Practice has been around for a long time (web browser did it for parallelizing the initial delays.) We do not want to condemn the practice, but it is poorly documented and understood, full of hacks and extra control loops. No IETF guidelines. This work item will fulfil this. It will provide guidance where appropriate. Are these bulk connections or idle? ??: We did do this work. If you go to small windows in TCP, fast retransmit will stop working. Min. window size makes it impossible to go to a coarse level. Maybe I should write it down and send it to the WG. Stas: Good, please do. Goals and milestones: by Oct. 2009 both documents will be delivered. Bob Briscoe: any new congestion control should not assume that it has no control over what share it has. We must have the network controlling everything and I want the congestion control algo to control everything and the network to help it. Endpoints should control flow. Stas: Not in charter. Tim Shephard: Quickly yield to TCP, do you mean yield to any protocol that is using the standard TCP congestion control algo. Ledbat App practices and Recommendations, Satish Raghunath, Juniper Goals: have you designed apps that use multiple connections, if so what motivated you. Bring up the benefits and problems of multiple connections. Went thru P2P and multiple connections. Middleboxes have problems because of state. David Oran: Not sympathetic with this problem. Stas: Middleboxes are in our charter. Joe: HOLB, demultiplexing, EOF signaling -- these things are not on your list. Need to be. ??: Many theories on why BT uses multiple connections; they are misinformed. Some game theoretic models being used here. Stas: BT uses multiple connections to get a connected mesh. Need user input regarding what is being done today. Lars provided some input on the intent of this work item. How many connections in general. May need a different document for how many connections for a less than best effort applications. Joe Touch: opening multiple connections to different hosts vs. openeing different connections to the same host. Need some guidance on what does it mean to coordinate different things between different systems. Lars: Finding out what apps are doing is the first step. Based on that we should give guidance regarding tradeoffs to app developers. On if the network should have a role: we need to tease that out and discuss what that is and what it should be and make it more clear. Maybe a work item that people have in their mind but not on paper. But we need to be sure on what that is. Illitch: What apps are in scope? We should declare apps that do not do bulk uploads (like browsers) out of scope. Stuart Cheshire: Opening many connection to the same web network for faster connections is not true. 1 connection too 17s, many connections took 2minutes. When you open a lot of connections, the 3-way handshake take a lot of time as does packet loss on a radio networks. Low priority TCP: Receive-Window control, Murari Sridharan, Microsoft This is a background transfer service, tightly couple capacity interface and rate control. Bryan Ford: How does this behave when a lot of low pri TCP connections are competing against each other? Murari: Cannot share the results right now. We have experimented with a highly congested link w/ a lot of ledbat type flows to see if it steals bandwidth. Bryan: TCP is unfair to flows that have a long RTT. How does this compare to your algo? Murari: Do not know, we have not done that comparison. Nicholas Weaver, ICSI: A couple of academic thoughts on LEDBAT. Two separate problems: Without the use of packet marking or AQM, detect buffer occupancy problems which are user local. Detect and yield in common congestion to other longer lived TCP-compatible flows -- the ISP scavenger flow problem. Don't know if there is one congestion control mechanism suitable for both problems? Second problem is well researched, why don't existing solutions (see Sally Floyd's page) apply? LEDBAT should be defined as a TCP operating mode -- only one side nneds to use the defined congestion control policy. Joe Touch: Third problem -- if you are on a link, especially on a slow link sending a large packet, the network will not preempt that packet because another packet with high priority comes in. Some techniques for dealing with this (Lars' dissertation, for example.) Bob Briscoe: There are dial-up modems that will preempt a large packet. Cannot expect that we can mark packets to say I am a good packet and don't be nasty to me. ??: We have b/w on demand networks; we need to factor this in here. Stanislav Shalonov, Low Extra Delay Background Transport Problem: TCP fills buffer, buffer can be 1s or more, interactive apps fail ==> "The Internet does not work." How large should the buffer be, anyway? For a home connection, the best buffer should should be: 50ms? 100ms? < 50ms? > 100ms? No right answer. Large buffer (1s) leads to standing queue. Illitch: Why buffer when you can retransmit? Status: We implemented a congestion control algo and deployed it on the BT client (7M users). Soon to be in mu-torrent. Will be a solution candidate for ledbat. By next IETF will have a draft. Some design issues: RTT vs. one-way delay. If you delay an ACK you have received incorrct congestion information. Noise filtering is another design issue. Use smaller packets on slow links Deteriorate to TCP -- increase no faster than TCP would and halve window on loss. Yield to TCP - straightforward b/c you get congestion notification before TCP, and if you react to congestion signal you will react before TCP and TCP is happy. Lars: What if you have new fangled TCP that also reacts to congestion delay? Stas: If TCP is also delay-based then the whole issue of yielding becomes complicated. But we are using TCP here as what is understood as standard congestion control. Murari: None of the widely deployed TCP are (only) delay based. Anja: How do you react to congestion on backbone links? Stas: You don't need to -- there is no congestion. If there are such things, you will end up behaving like TCP. Stas would like some more input from the group for text contribution and review. Meeting ended 15:00.