Transport Area Meeting (TSVAREA) Minutes - 3rd Draft IETF-68, Prague, Czech Republic Hilton Prague, Congress III Tuesday, March 20, 2007, 1520-1720 Afternoon Session II Chairs: Lars Eggert Minutes: Gorry Fairhurst AGENDA (1) Administrativa Note Well Scribes Agenda Bashing (2) New WG Overview: Congestion and Pre-Congestion Notification (PCN) Scott Bradner and Steven Blake (3) Bringing Experimental High-Speed Congestion Control to the IETF Lars Eggert (4) Vista Implementation Report on ECN/FRTO/WS/DSACK Dave Thaler and Murari Sridharan (5) Wrap-Up MEETING REPORT (1) Administrativa Gorry Fairhurst volunteered as minutes taker. (2) New WG Overview: Congestion and Pre-Congestion Notification (PCN) Review of charter presented by Steven Blake: The Congestion and Pre-congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established inelastic flows within a DiffServ domain when congestion is imminent or existing. The focus of the WG is on developing standards for the marking behavior of the interior nodes and the encoding and transport of the congestion information. Reaction mechanisms at the boundary consist of flow consist of flow admission and flow termination. Pekka Savola: Does the DiffServ area using PCN have to support NSIS, etc? Steven Blake: No, it can use other configuration methods. Bob Briscoe: Background to slide saying goal of PCN isn't to get last percent of utilization from capacity: PCN-based admission control itself allows far superior utilization of capacity than say admission control solely at edges of a Diffserv domain. Steven Blake: The scope of the PCN charter has been constrained to a single domain, and therefore what can be done in a consistent domain. (3) Bringing Experimental High-Speed Congestion Control to the IETF Presented by Lars Eggert: Described taking CC research and getting experience into the IETF. The IETF would all like to evolve TCP forward, there is lots of research, but we do not anymore know what stacks actually do. Comment: BIC is disabled in Linux. Lars Eggert: Some distributions of Unix come with QBIC enabled. Tim Shephard: It depends on who compiles the Linux kernel. Lars Eggert: We need to know at the iETF what is actually being done. If we do not, we could be losing contact with our developer community. The IETF wants to provide a venue for moving the TCP specifications forward. Goals differ depending on the document type: * To document current stacks behavior - e.g., Informational. * A proposal for eventual standardization - e.g., Experimental. There will be new procedures for review, initially via the ICCRG. Aaron Falk: If you have a desire for the RFC Ed to do something specific and use new procedures, you need to tell them what to do. Gorry Fairhurst: The slide says this will be done "Out of the TSV Area". What does this really mean? Lars Eggert: It means, the work will be done in the TSV Area. Bob Briscoe: Why are people not taking this to the IETF? Is putting two hurdles (of review) likely to be better? Lars Eggert: It has in the past taken the Transport Area some time to evaluate new methods, and we want to make a better procedure for this. Tim Shephard: QBIC is turned on in my laptop! (I was surprised). Comment: Mine too! Aaron Falk: In the case of QBIC, the researcher who developed this, did not ask for this to happen. There is no suggested process that describes the right thing to do, and to give the stack vendors some endorsement of the right way. Tim: I agree. Lars Eggert: This was presented to the ICCRG, and they thought this would work. A hum at the end of the presentation showed strong consensus for the proposed approach. (4) Vista Implementation Report on ECN/FRTO/WS/DSACK Presented by Dave Thaler on behalf of Murari Sridharan, Deepak Bansal: Microsoft started a new TCP/IP stack in 2001, shipped in Windows Vista, including: Window Scaling (RFC 1323, PS) ECN (RFC 3168, PS) DSACK (RFC 3708, EXPERIMENTAL) F-RTO (RFC 4138, EXPERIMENTAL) RFC1323 was previously in Windows, but was off by default. Deployment problems. The core issue was broken firewall logic that does not scale window in TCP headers correctly while determining how much data to let through, this lead to a scale factor of 2. Kevin Fall: Is RFC1323 support limited? or configurable? Dave Thaler: It's configurable, and if you wish, you can change it. Dave Thaler described problems with gateways, etc. that lead to interoperability issues. Tim Shepherd: Each side says how to do window-scaling. Are these bidirectional problems? Dave Thaler: We don't know. Mark Handley: How do we get rid of the busted boxes out there? Dave Thaler: Is this an IETF question? Mark Handley: (retake) What should the industry do? Dave Thaler: There's a logo "way" of doing this - products with a Vista logo indicate they should support it. Lars Eggert: Can you offer diagnostic tools in the session? Dave Thaler: Yes, we have thought about that. Dave Thaler: ECN (RFC 3168) was easy to implement, but can lead to a (home) internet gateway crash. David Oran: Is the "gateway" a router on the path? Dave Thaler: It is likely to be a (small) home router. Randall Stewart: Is this an IP effect? Dave Thaler: Yes. David Oran: Was behavior different when NAT was turned on/off? Dave Thaler: We do not know if this was tested. Tim Shephard: What is meant as "easily detected" in the slides? Dave Thaler: Can be detected by the sender, which means you can re-send a new replacement SYN. Michael Richardson: Firewalls in front of web servers have long been advocated for commercial web servers. This advice needs to be changed. It would be nice to call up a bank and say we can not use some specific application using a well-known operating system... These devices can also lead to Path MTU problems. Dave Thaler: There is an ECN "Hall of Shame" that does a test on a web-site, and reports its compliance. Because of deployment challenges, ECN is by default off in Vista. Mark Handley: Can you leave it on, when using listen sockets, so that you can let the systems evolve? Dave Thaler: Vista-Server has not yet shipped and could have this on by default - this feedback is useful. Dave Thaler: No issues were found with DSACK (RFC 3708), this is on by default in Vista. No issues were found with F-RTO (RFC 4138), this is on by default. Bob Briscoe: Can the two things that have turned-off by default be controlled remotely in a corporate environment? Dave Thaler: Yes. Dave Thaler: Details of the implementation experience may be found at: http://support.microsoft.com/kb/934430. (5) Wrap-Up Lars Eggert encouraged people to tell the ADs of interesting topics for future TSV Area meetings.