[Iccrg] Slides from my talk
keshav@uwaterloo.ca (S. Keshav) Tue, 13 February 2007 15:32 UTC
From: keshav@uwaterloo.ca
Date: Tue, 13 Feb 2007 15:32:16 +0000
Subject: [Iccrg] Slides from my talk
Message-ID: <EA8DDF0C-0774-46E6-9DAB-DDB90CDE8621@uwaterloo.ca>
X-Date: Tue Feb 13 15:32:16 2007
are attached... keshav -------------- next part -------------- A non-text attachment was scrubbed... Name: congestion.pdf Type: application/pdf Size: 47636 bytes Desc: not available Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070212/ebd5c90a/congestion-0001.pdf >From michael.welzl@uibk.ac.at Mon Feb 19 10:40:00 2007 From: michael.welzl@uibk.ac.at (Michael Welzl) Date: Mon Feb 19 10:42:08 2007 Subject: [Iccrg] Meeting material Message-ID: <1171881565.3698.63.camel@pc105-c703.uibk.ac.at> Dear all, Below you'll find the minutes from our meeting (thanks to Kashif). The slides are available from: http://www1.tools.ietf.org/group/irtf/trac/wiki/Agenda Cheers, Michael ---- IRTF ICCRG meeting, 12/13 February 2007, ISI, Marina Del Rey, CA USA Day-1 Session # 1: Michael Welzl: "Current State of ICCRG" Additions in existing RFCs and drafts Role of IETF in Congestion Control issues Move to high-speed TCPs? Comments and issues raised by Aaron Falk, Lars Eggert, Bob Briscoe, Larry Dunn, Ted Faber Tim Shepard (about current cc survey draft): how to distinguish between QoS and CC? Michael Welzl: group should suggest the inclusion of a particular RFC if desired Keshav: "What is Congestion and what is congestion control?" Congestion is reduction in utility due to overload in networks that support both spatial and temporal multiplexing but no reservation. Solution schemas exist, but inherently complex. Delays due to temporal multiplexing were discussed. Delays due to small buffers. Comments and issues raised by Bob Briscoe, Tim Shepard, Doan Hoang Chris Christou: "The role of the Transport Layer in Delivering an Assured Elastic Service: GIG Network types, GIG converged Services and Precedence" Behavioral model for an assured elastic service. Focus on implementing the Assured Elastic Service. Requirements for the assured elastic service and the work to date raise several questions. Performance challenges were discussed in the role of the transport layer. Summary: DoD intends to implement the RFC 4594 service classes in the GIG, including Assured Elastic. Broad view of Assured elastic implementation that enables the transport layer and congestion control to play a major role. Interest in contributing to the ICCRG Problem statement draft. Comments from Aaron Falk. Question by Larry answered by Chris. Session # 2: K.K Ramakrishnan: "LT-TCP: Loss Tolerant TCP" Goal: Extend the dynamic range of TCP into high loss regimes. Results show that performance of LT-TCP is much better compared to that of TCP-SACK. Results were also given for co-channel interference LT-TCP provides robustness even under conditions of large and burst loss rates. Gives increased dynamic range, high good put, and avoids timeouts. Lachlan Andrew: "Rate control with packet corruption" Nandita Dukkipati: Announcement of workshop at Stanford Nandita announced a workshop at Stanford for the need of new transport or high speed protocols. Questions by Michael Welzl, Bob Briscoe, Ted Faber Session # 3: Lars Eggert: "Experimental congestion control proposals and IETF/IAB/ICCRG" An evolved TCP needs to be a safe standard. Question by Tim Sheppard: What if you open multiple connections? Interest in new CC features for major TCP stacks (BIC & CUBIC in Linux and CTCP in Windows vista) IETF is the originator and maintainer of TCP IETF/IRTF involvement: implementers of new CC mechanisms should bring them to IETF/IRTF Class-1: Document current stack behavior Which subset of the specifications is implemented and ignored? Future examples? - Linux: delayed-ACK suppression during slow-start - Vista: impact of enabling ECN, window-scaling etc. Class-2: Experimental specifications Goal: Mechanisms that may eventually progress onto the standards track. Internet-drafts intended for experimental RFC Proposed approach, Phase 1 Work split between IETF and IRTF, bring individual internet draft to ICCRG first. ICCRG reviews draft and existing body of work. After ICCRG consensus, send draft reviews to TSV area. If adopted, publish experimental RFC out of the TSV area Aaron Falk: If something is not ready for wide-scale deployment, experimental RFC will label it, don?t use it as default. Experimental, not Informational for documentation of (past) experiments. Proposed approach, Phase 2 IETF is not a research organization but IRTF is. ICCRG coordinates this effort. Bob Briscoe: What are you trying to achieve by doing that? Doan Hoang: a paragraph for security may be added Ted Faber: What is the incentive for IRTF to do that? Interoperating information? Session # 4: Discussion: What should the ICCRG be doing? Main points of discussion: To review a protocol criteria for ?safe? (?good?, e.g., performance etc) pass/fail safety criteria as an initial step? hard test cases vs. soft guidelines? List of things proposers need to bring to the RG Initial spec & paper citations with data Use TMRG scenarios & metrics RG review is iterative process Organization of the structure and reviews H-TCP is there, CUBIC and C-TCP coming soon Clarify the benefit of the process to the proposer Day-2: Session # 1: Tom Phelan: "DCCP, TFRC and Open Problems in congestion control for media applications" Discussion on defining what is ?congestion collapse? by Bob Briscoe, Tim Shepard, Michael Welzl and Tom Phelan (Ted Faber and) Eric Coe: "Congestion control with explicit feedback" Doan B. Hoang: "FICC-Diffserv: using CC as a QoS element" Bob Briscoe: "Flow rate Fairness: Dismantling a Religion" Discussion on fairness Final discussion: Michael Welzl: can we use the procedure from Lars Eggert's talk for other cc. proposals too? Tim Shepard: should ask the list, many attendees have already left the meeting. Lars Eggert: should not be a mandatory procedure for anything other than high-speed-TCP proposals Michael Welzl: so it's totally voluntarily, no need to formally agree on anything
- [Iccrg] Slides from my talk S. Keshav