LEDBAT IETF 77 Meeting Agenda Chairs: S. Shalunov M. Sridharan Monday, March 22, 2010 0900-1130 Manhattan Preliminaries (10 minutes) Note well Blue Sheets Minute Takers - Dave McDysan Jabber Scribe - No volunteers? Agenda bashing - No commments Document Status - Murari summarized slides, no comments See http://www.ietf.org/proceedings/10mar/slides/ledbat-1.pdf 9:10 - 9:40 LEDBAT Practices and Recommendations, R. Penno (30 minutes) http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendation s-01.txt Renaldo presented: http://www.ietf.org/proceedings/10mar/slides/ledbat-0.pdf Murari Q: Is recommendation of less than 6 connections needed if window scale implemented? REC-3: Applications in general should not open more than 6 connections to download the same object. A: Yes, but another issue is server bandwidth limit per connection. Murari Q: How would client know about this server restriction? Stuart Chesire (Apple): Guidelines apply to http but not necessarily appropriate for other applications. Easier for server to send as fast as possible and let TCP flow control work. Opening 6 connections will create more load on the server than one. Mathis: Institutionalizing workarounds (such as this) for a problem is a dangerous road. Renaldo: Proposed rewording recommendation for "purposes of throughput" Murari: Capture disucssion in document. Chesire: Why 6 instead of 5 or 7. Recommending that this be one. Stan: Focus should be on the reason for multiple connections (e.g., control/ data is OK), or for throughput (probably not OK). Janai (sp?) Franklin/ Marshall College: Is any number needed? Discussion of pros/cons should be in document. Joe Touch: Proposed wording: "Apps should not open multiple connections for the sole purpose of increasing throughput." Emphasis on "sole" Dave McDysan: Suggested adding the impact on NAT, especially IPv6 Carrier Grade NAT which would be impacted by multiple TCP connections. Renaldo: More materia Matthew Kaufmann (Adobe): Agree with "sole." Other protocols do not have this problem. Stan: Only TCP, other protocols out of scope. REC-4: HTTP based applications should use HTTP/1.1 pipelining when transferring multiple small objects from the same server. Joe Touch: Differentiate between persistent connections (OK) and pipelining (possibly not OK in some situations). Chesire: Is the draft mixing up http and TCP? What is the focus: server developers, application developers, robust clients. Polly (Apple): Need to tolerate buggy servers (e.g., transparent proxies). Lars Eggert: Recommend the good thing to do and what is realistic (i.e., under what conditions environments can it be used). Similar to ECN and other Diffserv marking in this sense. REC-5: Application developers should provide users with a way to configure the number of concurrent TCP connections used to transfer a single object. Lars: Specifying the conditions under which such a number/knob should be used. Stanislav: Majority of users will not use such configuration options, and those who do may not forsee consequences of such configuration. Fraction who can do something useful is small, but they are vocal. Murari: Make specific to applications. Lars: Should list specific applications in the draft. Suggest stating as configure the upper limit. KK Ramakrishnan: Goals: improve thruput, separate control/data, HOL blocking versus increase in state. Is an aspect that of different remote end points? Herbert Koogle: Since most web objects are small is goal to eliminate slow start. Renaldo: Yes, but also avoidance of HOL blocking. Joe Touch: Pipelining as a general concept is OK, but HTTP 1.1 version has issues and that is why it is turned off. * Bi-directional HTTP - HyBi working group effort at IETF Lars: Seems to be outside of charter (http specific) and may be out of scope. Mark Polly: http is fundamental impedance mismatch with modern web browsing. Originally, http pulled down one object while now http retrieves a page with multiple objects. Joe Touch: Can cite publications that describe this mismatch. Stanislav: True, but this seems out of scope. Joe: Recommends pointing to papers. Lars: http is good example that uses multiple TCP connections. OK to use http and ftp as examples, but DON't make recommendations about the applications. Chesire: HOL blocking is an issue if browser wants to display page before all objects are received; however, other apps (e.g., audio/video.program) everything needs to be downloaded. Joe: Pieplining for a single object can impact other objects. Amazon example given. Chesire: Scope was a single object. Mark Polly: Webdav has a similar issue. Renaldo recap: Reword following: - sole purpose of multiple connections is to increase - Summarize why pipelining is broken, what is needed - REC-5 configuration reworded based upon Lars' comments 9:40 - 10:10 LEDBAT Congestion Architecture, M. Arumaithurai (30 minutes) http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-0 0 Mayutan presented http://www.ietf.org/proceedings/10mar/slides/ledbat-2.pdf Murari: Appears more appropriate for iccrg. Context could be architectural framework. Not sure decoupling is such a good idea, way that everything works together is more important. KK Ramakrishnan: Proposing a framework as useful to think about the components of the protocol and how they fit together and interact with other mechanisms. Stanislav: Specific comments on the wg spec and any suggestions as to what should be changed? KK: If/when network supports explicit congestion notification, how could this be plugged in. Better estimate of fair share as a target for exploration instead of a delay based scheme. Murari: ECN is TCP-based, ledbat is striving to be more general. Arami (sp?) Cisco: No mention of RED? Why not? Murari: Not clear if RED is available in cable modems. Stan: From charter, AQM is a more generic term that includes RED. Janai: One use is a clear separation of constants in the congestion draft (e.g., the max latency of 25 ms). Introduce more flexibility into the experimental solution in terms of configurable constants. Stan: Inconsistent with wg comments from last meeting where feedback was to pick specific values. Jana: Don't use MUST, but move to recommendations. Stan: MUST is needed for interoperability. Lars: Use specified value for interoperability, but does not preclude experimentation with other values. KK: Specific feedback requested on draft. Murari: Could use bandwidth estimate, feedback instead of or in complementary way with delay estimation. Stanislav: Provide specific text changes on congestion. Bob Briscoe: Add specific text to describe how ledbat congestion interacts with ECN. 10:10 - 10:40 Low Extra Delay Background Transport (LEDBAT), S. Shalunov (30 minutes) http://tools.ietf.org/html/draft-ietf-ledbat-congestion-00 Stanislav presented http://www.ietf.org/proceedings/10mar/slides/ledbat-3.pdf Lars: This draft missed the cutoff and was noted in the meeting. Stanislav: Tentative proposed text changes, premilinary version sent to mailing list, will follow up with a version -01 based upon feedback received. Fairness Lars: Measurements in Trilogy project is not enough, minutes may be needed to determine baseline delay measurement. Explicit randomization should help. Rolf Winter NEC: An issue is one minute slots for base delay, with history of ten minutes. A long delay in a one minute slot will not be aged out until ten minutes. Stanislav: Clarification, inserts small random (zero mean) values to delay which changes amount of capacity that is distributed to other flows. Paramter should be related to the target. Prameter Values: Dave McDysan: Question on clarification of interoperability related to different implementations achieving similar performance. Stanislav: Stronger than that, is a distributed algorithm where the implementations interact. For example, in a shared bottleneck two implementations with similar demand should get a fair share of the bottleneck bandwidth. Covers all issues? Rolf: DSL case in rural areas has a lower rate. More than 25 ms can occur at lower rates. Should segment size be reduced for these lower speed links. Stanislav: Preliminary algorithm for adapting segment size has been developed, but not as well baked as other work. It adds considerable complications. Rolf: Agrees that this is not trivial, and recommends saying something about this in the draft. Stan: If serialization exceeds the target, then ledbat should work. Rolf: But does not do what was specified. Home Gateways do more than FIFO/ drop tail for European market. For example, multiple queues voice, BE, Lower Effort. P2P can be classified as Worse than Best Effort, which is in a different queue and hence delay measurements don't work. Stanislav: Requested more info on this. Murari: Requested a formal presentation at the next meeting on measurements performed. Cheshire: This may not be an issue, putting lower effort in another queue has been done by the home gateway. Lars: These are points for discussion on applicability of draft. Also, extension on packet (segment) size is problematic. Nothing stops wg from moving current draft for stable baseline to experimental and then make other extensions, such as variable segment size as future experimental drafts. Lars: Confirmation of stability to be done on mailing list, then run last call on the mailing list. Lars/KK: State underlying assumptions in draft (e.g., ledbat traffic shares bottleneck queue with foreground traffic). Detailed Text slides are in the distributed deck, and are also on the mailing list. Jana: Doesn't seem to address issue if off_Target is high then Ceiling could increase due to a long cumulative ACK (e.g., due to prior ACKs being lost), back-back ACKs and bursty behavior could result. Stan: Increases in ceiling are bounded and are no more than TCP. Murari: Reframed question as to how acknowledgements are received and the packets are "released" and not necessarily how congestion window (ceiling in Jana's question) increases. Such behavior will cause measured delay to increase. Stan: Pseudocode on slide 16 cwnd += GAIN * off_target / cwnd is increase once per RTT Pseudocode applies to one ACK per packet (for exposition purposes). Lars: Summarize the issue in the draft and consider this as a possible future extension. Mathis: Number of TCP implementations behave this way and result in "stretch ACKs." Consequence is that measured delay momentarily increases and throughput decreases. Stanislav: Ultimate solution is rate-based instead of window-based. However, straightforward port to rate-based does not work as well as window-based. Jana: State assumption that ACKs must be sent (and received) frequently for the spec to work. Stan: Will add this to framing considerations. ??: Separate specification from implementation recommendations in separate documents Stan: Could be a later document when to not use SHOULD in original spec for a particular environment. Murari: Asking for experimental data? Cheshire: Supports having one clear document. Avoid making things too general. Reggisio (??): Recommend assuming ACK per data packet. Stan: However, doesn't address case of multiple lost ACKs. KK: Suggested trying to understand to burst release of data from one or more sources that could cause impact on other flows. A Survey of Lower-than-Best-Effort Transport Protocols (No Presentation, updated document) http://tools.ietf.org/html/draft-ietf-ledbat-survey-00 Next Steps and Wrapup (20 minutes)