[Iccrg] Notes from the meeting

[Michael Welzl]

Hi all,

Please find the meeting notes below; apologies if I missed
something important.

I also uploaded the slides which I received so far to the agenda:
http://trac.tools.ietf.org/group/irtf/trac/wiki/AgendaMay09
Bob, Matt, please send me yours, I'll include them too as soon
as I get them.

Cheers,
Michael

--------


Meeting minutes of the ICCRG meeting in Akihabara, Tokyo, 22. 7. 2009

Participants: Michael Welzl, Michael Scharf, Bob Briscoe, Le Hieu Hanh,
Kevin Mills, Takashi Takesue, Matt Mathis, Ilpo Jarvinen, Ryousei
Takano, Michio Honda, Yoichi Inanaga, Yusuke Miyoshi, Kazuya Tsukamoto,
Kaysosli Kabayashi


Michael Welzl talk: agenda bashing - Discussion about
draft-housley-iesg-rfc3932bis stopping progress of
draft-irtf-iccrg-cc-rfcs (together with several other IRTF drafts). Bob:
A survey becomes less and less useful as time goes by. Lars: This issue
has just been discussed in an IAB meeting, things will probably move
ahead now.

Michael Welzl talk: open issues draft
( draft-irtf-iccrg-welzl-congestion-control-open-research-04
 ) - no discussion happened. Matt: this is a useful document. The
authors believe that this draft is ready for "last call", people should
(re-)read and comment.

Matt Mathis talk: touched upon various issues; discussion about window
scaling - apparently Windows Vista uses an 8meg buffer and larger TCP
window scaling for everything except for the web browser. This will
change the network and show people that AIMD doesn't work well, e.g.
with current home modems that have large queues.

Michael Scharf talk: quick-start algorithms: discussion with bob briscoe
about details of the proposed algorithm.

Kevin Mills talk: in-depth evaluation of some TCP protocols. FAST
behavior stands out; some discussion about the underlying model.

"Beyond TCP-friendliness" design team discussion. Bob introduced the
plan with slides. Discussion: realistic ways to get this deployed,
relationship to / service provided by re-ecn, ...

This design team is not the same as, but connected to, Bob's Re-ECN IETF
effort called congestion exposure ("congestion transparency"). It is the
goal of re-ecn to expose congestion.

The ICCRG design team:
* should discuss issues around weighting of congestion controls and
provide
  a direction for the ietf regarding different views on resource sharing
* is connected to congestion exposure as one use case. Michael Welzl:
implementing
  something like Re-ECN on the end system only could be a second use
case (more tangible,
  because it doesn't require ISP involvement). Agreement.

Michael Scharf: how does congestion charging relate to volume
charging? answered by Bob with slides.

Michael Scharf also mentioned two use cases that are related to
congestion
exposure and that are maybe interesting use cases beyond congestion
control, even though he is not sure whether it is possible to come up
with a simple solution, and whether they are indeed within the scope
of the design team:
- From the user perspective: Detecting capacity overbooking by ISPs
  (Bob: Re-ECN could help here)
- From a business customer perspective: SLA verification and performance
  problems root cause analysis (e. g., if application performance is
poor,
  is this due to congestion on the path, and if so, on which part
  on the path?)


The design team will use the main ICCRG list. its charter should be
discussed in
the list. it should have a simple web page, maintained by Bob and Matt,
which has the charter and some key information / documents about the
team.



---

This meeting was supported by the JSPS 163rd committee on Internet
Technology (ITRC).