Subject: [re-ECN] DRAFT minutes for CONEX IETF 77 Session 1

From: Leslie Daigle <[email-masked]>
Date: Tue, 30 Mar 2010 13:11:13 -0400

Hi,

Thanks to John Leslie & Matt Zekauskus for taking notes, and to Ted 
Hardie for being our jabber scribe for the session.

Please find below an amalgamated set of draft notes for the minutes. 
Comments and corrections by Wed Apr 7, if you would be so kind!

Thanks,
Leslie.

CONEX BoF, Session 1
March 24, 2010
15h10-16h10

Chairs:  Leslie Daigle & Philip Eardley
Jabber Scribe:  Ted Hardie
Note takers:  John Leslie, Matt Zekauskas

Leslie reviews what's been happening: BarBoF Stockholm, GIIC workshop,
BoF in Hiroshima; two key questions there: "is conex a problem" YES; "is
there IETF work here" YES.  Followed up with draft charter, which
provoked IESG comments; hence this BoF: why Congestion Exposure,
response to IESG comments; need clarity, charter outline; looking for
clarity in charter text; agenda for tomorrow will be posted after today.

Want to clarify: there are 3 pieces: (1) generative technology, (2) 
deployable uses, (3) one implementation, re-ECN, (basis for believing this
is worth pursuing); hard to keep these three separate; want to focus on
first today.

  From the slides: congestion exposure is "A mechanism by which IP
datagrams can signal the total rest-of-path congestion that they are
expecting along the entire path they are traversing."

Three presentations

Presentation: Mat Ford, Some data from ISOC panel in IETF76
Briefing paper published yesterday

Access networks getting faster; pressure from broadband, etc.
Data of Japanese market, over four years
Internet Observatory: private peering bringing content "closer"
Pinch Points: CPE (typically no AQM), aggregation routers, interconnects
Impact of individual subscribers increases; additional capacity may not
be cost-effective; tools limited

Questions?
Hannes Tschofenig: also MIT project to run similar analysis, should be
available in a few months
David McDyson: is it in-charter to look at incentives to balance?

Presentation:  Richard Woundy, ISP perspective
Three areas of concerns: customers & activities, external third parties,
our own network; impact on customers is key -- customers calling -- do
we know why there's congestion?
Regulators are asking us what effect on customers & how do customers
learn of issues
Fixing congestion tends to require truck-runs -- may be delayed by
weather, etc. Demand may double by the time you fix problem
We want low-volume traffic not disturbed by high-volume uses; we want
customers to be able to prioritize their uses
Potential Use Cases: input to congestion mgmt; discovery/diagnosis of
issues; possible DDoS mitigation; incent LEDBAT-like applications; 
congestion can occur in many places;
customers report trouble on social-neworking sites and blogs (example
where diagnosis was particularly difficult
"Why don't you get back to me when you have something deployed" --
understandable
Two "ecosystems": implementation ecosystem, network-deployment ecosystem
-- engineering issues, not research issues

Phil: use cases later, but use cases not in scope yet
Hannes: valuable insight from Rich's presentation of Comcast's
experiences, wish other providers would give similar info; what can be
done today with existing tools; interesting properties, e.g.
protocol-agnostic

Presentation:  Alissa Cooper -- Traffic Management tools & techniques
Reasons why providers do traffic management
Easier to deploy, cheaper than expanding, build-out schedules,
fine-grained control
Throwing capacity at it: straightforward, meets demand; but expensive,
can't solve congestion on other networks, spreads cost to those who
don't need more capacity
Approaches: volume, rate, applications; what metric to take action, what
action to take
Volume caps, volume penalties; but impact too restrictive in times of
low traffic, insufficient in times of very high volume
Rate-limit, simple to implement; but too-much/too-little restriction
Application-based: sensitive to use characteristics; but cat & mouse,
public-policy issues
Combinations...
Benefits of Congestion Exposure
Incentivizes reduced-congestion protocols like LEDBAT; Exposes 
congestion end-to-end, across network borders; transparency at every 
network node (good for
capacity planning); enables Internet-wide solutions

David McDysan: seems more access-network applications; focus on
use-cases including access networks and transit networks, wireless
access networks, collect/distill to prioritize requirements

Leslie: good point. Is everyone clear on what problem is and the scope
of impact.?

silence...

Leslie:  Everyone seems to be clear on the scope, based on the "silence
is agreement" model.

Phil projects slide with Framework of charter
Leslie: Now on to the Charter text discussion.  Not all will get
discussed today, but the meeting tomorrow will pick up where we leave
off today -- please be sure to come back tomorrow as well.
Phil: slide "the generative technologies" -- the major work item (in v4
and v6); how to carry congestion information

Manesh ?? (microsoft): seems to be wired-network specific, need more
input from wireless operators
Phil: that wasn't on slide
Matt Mathias:  worth doing the exercise of some "test marketing" -- take
this paragraph to people that haven't read it before, watch them read
it ask if know what means.  It would help to ask such folks to explain
what they think it says
Leslie: to a large degree this session's primary purpose is to clarify
this text so it reflects what we agree are the tractable work items for
a WG.
Hannes: would be good to involve cellular operators in this discussion;
problems & resolutions are different.
Ingemar Johansson: Plan to submit a document on wireless aspects

Lars: a little disappointed,  one reason why approved second bof was
because we had strong consensus, but IESG issues.  Would have liked to
see more people wearing dots to understand if issues resolved or not.
Hoped to clarify the issues, would have been best to hear issues today
and come back tomorrow for answers; I wonder if this has helped at all

Adrian Farrell (IESG member): didn't find this helpful for issues which
came up; difficult to grok, "given my previous experience this is my
expectation of what congestion I may see in the future".    Once had
parsed that, he was able to understand where the group was going, but he
is still not convinced that there is demand for it.  He is cautious
about burning cycles on items that might not get traction.

Leslie: Happy to address the detailed comments once the core question of
whether this IETF or IRTF work; she had hoped that the presentations
today would address that.

Andrew McLaughlin: I don't understand how we're going to deploy this
among service providers.

Appreciation expressed for Adrian stepping up to the microphone --
others voiced private concerns, Adrian helped by voicing publically.

Lars: good place to stop; you can corner Adrian before tomorrow.

David Harrington: I had some concerns about how this is to be used
between providers, specifically the incentive to cheat

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------