[Iccrg] Meeting material

[Michael Welzl]

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