RG has 2 I-Ds and 2 TCPM reviews in progress

Meeting in Manchester went well

need to finish the cc-rfcs draft, no objections expressed

need people to review CUBIC

Compound TCP Review:

Mark Allman: didn't find experiments to be convincing of safety for
experimental deployment on the public Internet

Wes: most of group's confidence came from the delay-based
component only being triggered under cases of low loss and
high congestion window

Allman: nobody showed me; I don't know if it's safe or not,
I don't find the argument convincing

Murari: offered to make more experimental results available,
pointed to results about loss generation and other details;
trying to separate mathematical aspects of protocol design
and implementation, wondering how experimentation aspects
come in

Tim Shepard: do we have a definition of what it means to
be "safe"; what are we trying to do, just get a feeling
or something better defined.
...
There are people who have turned UDP apps with no congestion
control loose on the Internet, how high do we set the bar?

Lars Eggert: safe for experimental on public Internet is the
best possible recommendation that the group can make, and
we'd like to get the maximum level for each proposal that
the group is comfortable with

Allman: RFC 5033 is a list of criteria for IETF to use when
thinking about alternate congestion control

TCPM may go point-by-point through that; maybe the RG needs
to make a similar list for "safety"

Wes: does TCPM want a short/quick review or a long review
with full consensus?

Allman: not a question for me, one for TCPM; it may be that
what we want is quick data

Murari: safety is not as open-ended as claimed, Sally's
draft on general criteria for CC gives criteria and has
a notion of what is safe to be deployed; we used high-speed
as a "gold standard" since it was already accepted for
experimental use on the Internet

Allman: it isn't concrete in what is needed to clear each
hurdle, it just forces you to think about each issue

Lars Eggert: we could show the "worst case" behavior of each
proposal, listing the conditions under which it would misfire
and go astray ... show when it's unsafe rather than when it's
safe.  this is half-baked

Larry Dunn: it strikes me that we started out with what we
thought would be easy and shyed away from strict set of
hoops to jump through.  now, the group needs to figure out
how to progress; an exit-strategy.

Murari: we have a private email exchange with Sally that I
can forward to list about the worst-case behavior of CTCP;
in the worst-case it's only as bad as High-Speed.  We don't
want the criteria to be too open-ended or keep changing.
One way to break protocol is cases where delay can't be
sensed, but during those times, delay window increases only
as High-Speed's would.  Lachlan and Doug did a clean-slate
implementation based on the I-D and had good results, their
slides were at the Manchester meeting.

Allman: task for RG is to figure out how to make these
decisions, whether quick or consensus.  as a first step,
the RG should decide and then ask TCPM if that's useful.
(with comments from Larry Dunn about this)

Lars: nobody has a problem when papers are written, but
only when we sit down as a group, it seems.

Wes: could put a threshold on number of reviews needed and
wrap up after that.

Larry: people are a little more careful when saying it's
safe here has consequences if they're wrong

Murari: hoping for agreement on what criteria are, and took
the approach of not enabling by default, going through IETF,
etc., so was hoping for a quicker process through this group

Matt Mathis: could also make weaker statements like "there
are no known situations with bad behavior"

Lars: agree with what Murari said; don't want to penalize for
bringing things here; need to move forward

Wes: (poll how many have read the draft) (half the room)
(how many would be scared if it was turned on in the
Internet) (none)

group in the room is in agreement that Compound isn't scary
if turned loose on net

Tim: I have no fear, people have done worse on the Internet,
an application could open hundreds of connections or
thousands all at once; there's a book about bridges always
failing from time to time and people die from it, but
bridges will continue to be built; I don't advise to wait
for this group to make a decision

Matt: and standard TCP behavior isn't safe; LAN people starve
out WAN people, and is worse than anything CTCP can do

Bob Briscoe: separate out the question: "is its dynamics fair",
about congestion colapse, backing off, and then "is it fair"
which can't be made by looking at the protocol, can only
decide if its dynamics are safe

Larry: "experiment is going to be the planet" probably puts
people off from saying okey-dokey.

Murari: Al Greenberg remarked that congestion control experts
have a hell of a lot of ego since there is so much control
in the network that end-hosts can't break the Internet down,
the real problem is in the enterprise; Microsoft used CTCP
internally on their network and watched it

Aaron Falk: is the Hamilton assessment that it's safe for
use on the global Internet?

basically, it seems so; some suggestions for clarifying and
qualifying about specific things (wireless, security, samples,
estimation)

Aaron: that analysis is key; might affect Mark's stance;
people have looked at this closely, done analysis, if RG
accepts that deeper analysis, and if Mark accepts that, we
can go forward with this

Mark: "I'm just one dude"

Aaron: what is the format of the recommendation the group
makes; is Doug's analysis published?  we should bind these
things together that says the ICCRG feels this way given
this
Mark: would be great with a bunch of references to papers,
mail messages, etc.
agreement from Aaron, Larry, Wes

***
RG will produce synthesized version of review with citations
to in-depth reviews
***

Murari: 3 independent implementations, Doug even thought we
were "not agressive enough" in some cases, that's why he
didn't want to say anything about performance benefits

unknown: what does it mean when the group says "safe for
experimental deployment"?

Wes: publication as experimental RFC?

hasn't it already been deployed in that sense?

Lars: anyone can run whatever they want without an RFC, but
eventually you want something on the standards track which
isn't going to come out of that

experimental can be interpreted as "okay to ship if off by
default"

Larry: we should package up how we treat CTCP, etc. vs how
High-Speed was treated and (joke) put Murari's home phone
number in the recommendation


Dimitri Papdimitriou - Open Discussion Points in the Open
Issues in Internet Congestion Control draft

2 challenges with work to be done are "small packets" and
"precedence for elastic traffic", had lots of feedback but
was left without text

small packets focused on TCP, TFRC, and TFRC-SP (long flows),
but not on short flows, need to further refine what the
specific design challenge is and the dependency on the
packet size itself.  Also discuss "is packet-congestible
world" even possible?

Gorry Fairhurst: applications in DCCP want to send packets
of some natural size

Dimitiri: focused just on differences and open issue is
the assumptions about the network behavior and data available
about validating through experimentation to grasp whether it
fits its initial objectives

Gorry: also looked at cwnd validation; some apps use the push
bit, so some TCP apps don't even generate constant sized
segments

would like to open discussion point on short flows and the
difference between this and small packets

want wireless, low-power, mesh, sensor networks, etc. to be
out-of-scope for "Internet" congestion control

upper layers, not just TCP, need congestion control e.g. P2PSIP

Wes: if we decide to leave things out, put in text that describes
why it was left out

multimedia codecs is another issue some have mentioned

Lars: low-power mesh stuff came from new ROLL WG where apps sit
directly on top of routing layer with no "overload prevention"

let's have discussion on the list, and next version will be
released soon

meeting adjourned