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

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

Hi,

Thanks to Mat Ford for the draft minutes attached (and, thanks again to 
our jabber scribe for the session, Ted Hardie).

Comments on these by Wed Apr 7, if you would be so kind!

Thanks,
Leslie.

THURSDAY, March 25, 2010
1510-1610  Afternoon Session II
California B        TSV     conex           Congestion Exposure BOF

Chairs: Phil Eardley, Leslie Daigle

Phil Eardley (PE) presents slides: 
http://www.ietf.org/proceedings/10mar/slides/conex-4.pdf

Gorry Fairhurst (GF) - You're talking about experimental modifications 
to IPv4 headers yes?

PE - Yes.

GF - Re-writing Proposed Standards and obsoleting them or updating them 
or what? Does the experimentation invalidate anything which is currently 
in PS or does it just use reserved bits?

PE - I believe it does not

GF - Does it invalidate anything which is currently experimental?

Bob Briscoe (BB) - If we're talking about re-ECN, you would have to 
update RFC791 to say that the last bit is no longer reserved but 
experimental. And then you'd have to write an Experimental RFC to use 
it. That process was used for ECN. The only other thing is ECN-nonce 
which is Experimental currently. We would have to work out a way to set 
that aside while we do this experiment.

GF - That was nicely worded.

Dave McDysan (DM) - In IPv6 we would have more degrees of freedom, 
potentially more capabilities in IPv6 using more bits.

Ingemar Johansson (IJ) - This work should be standards-track.

PE - We've already had strong feedback that work items should be 
Experimental rather than Standards Track.

Leslie Daigle (LD) - It's not a broken path to start with Experimental 
and then move to Standards Track if experiment is successful. There is 
consensus that the desired outcome is a standard.

Georgios Karagiannis (GK) - There are only two major work items - are 
others to follow?

PE - Yes, see later slides.

GK - When these bits are signalled across the network, the network has 
to do something with them - where is behaviour of the network specified?

PE - See later slides.

David Black (DB) - ECN was experimental for a time before it went to 
standards track.

Matt Mathis (MM) - There is another strategy here - talk about an 
abstract implementation and how functional units might work, and then 
map to a coding which forces you to give up some of the functions.

LD - We'll touch on that later in this talk.

IJ - Concept of conex is good. If it had been proposed 20 years ago 
would resistance have been higher or lower?

PE - We could discuss that over beer later.

Tim Shepard (TS) - I'm a fan of this technology, but my hope is that 20 
years from now it might be extensively deployed. I doubt we're going to 
see this inside of 10 years. But it's important to do the work now - if 
we don't it won't be here inside of 20 years.

LD - We're trying to unlatch requirement that says we have all the final 
answers and rather say lets get the work started - going for EXP 
acknowledges that we don't have all the right answers.

DM - I and others in my company have concerns about retrofitting this to 
IPv4 - should really be focussing this on IPv6.

PE - So you're happy with delivery, it's just about the process of 
getting there?

DM - Supports MM comment, there is another deliverable (abstract design) 
and the order is generic requirements and then that drives how you do 
the encodings.

Andrew McLachlan (AM) - If we're still counting congestion in 20 years 
then we've done something seriously wrong. Bandwidth is getting cheaper 
and cheaper and if we're still using congestion to measure congestion 
we've made a huge mistake somewhere along the line.

LD - Not agreeing with that point we need to move on and not argue it 
because if we argue it we'll be done with today's session.

PE continues with presentation

PE - Are people OK with this narrowed Charter?

MM - If this makes it easier to get past the IESG, then we should do it 
- we can always change the charter later.

PE - Are there any ADs in the room?

LD - The only question should be 'is this well-framed work for the IETF'?

John Leslie (JL) - I have no problem in principal with narrowing the 
charter, but I don't understand why this narrowing would make anyone 
happier, nor does it look like a good way to define a generative technology.

LD - Instead of trying to map out the entire path, this is what we do 
know today. This is the work that needs to get done in order to get the 
work started, and the use cases are the biggest unknowns, so moving them 
out seems like a non-lossy way to proceed.

Ross Callon (RC) - Former AD - personal opinion having heard other ADs 
discuss this is: this is interesting research that we don't think is 
going to get deployed in the Internet - unless we hear from a lot of 
service providers that they want to deploy. If narrowing the scope of 
the charter makes it clearer how we'll get this deployed then that is a 
good thing.

BB - Supports going for experimental status. It is very difficult for 
people to imagine what they might do with this until it exists. An 
experimental protocol that allows you to build a testbed and start using 
it allows people to understand what it is for. We're trying to prevent 
what happened with NATs happening with DPI (i.e. nothing is specified 
and we end up with a mess).

Rolf Winter (RW) - We have heard from operators that this is an 
important direction and they need a standardised solution. If we don't 
work on this now then we don't get to complain in 10 years when DPI is 
pervasive and breaking the network.

Jason Livingood (JL2) - Bob's last point was a good one - similar to 
NATs, if there's not something standardised in this space then you will 
see a lot of proprietary DPI devices deployed and that is a risk.

JL - I really don't even understand how you're proposing to narrow the 
charter.

LD - We are here to review the proposal to reduce the scope.

JL - I have no objection to a reduced charter.

RW - The narrowed scope addresses the problems raised, and leaves the 
core that we want to work on. Once we have made this initial piece work, 
there are probably additional things that will follow.

Ken Carlberg (KC) - Will IESG express their concerns publicly? Could 
they please be encouraged to do so?

LD - Yes, shadowboxing the IESG isn't fun.

DM - Will the charter be revised as MM proposed? IPv6 deployment could 
be enhanced if we focus there.

LD - Is your concern that we not focus exclusively on IPv4?

DM - Yes

MM - Coding for IPv4 is harder, so abstract design followed by coding 
work could help.

MM - Re future-historic tense - better sense: 'to allow all the elements 
along the path to get information about congestion all along the path'

Chris Morrow (CM) - We could do better with existing tools. I'm not sure 
I see a need for this.

LD - Were you in the room yesterday?

CM - No

LD - Check out the materials and minutes - the problem statement was 
extensively addressed.

CM - OK.

Adrian Farrell (AF) - I've caught every second word - had to be in 
another room. Experimental proposal gels with how I feel. I'm a little 
nervous about the use of the very last bit in IPv4, maybe we could cut 
it in half :) . An option might be to work on this in IPv6 first - if it 
flies there I might feel better about allocating the last IPv4 bit.

PE reviews proposed narrowing of use cases.

AF - was there any discussion about what the level of demand for this is?

LD presents Bob's analysis of support gleaned from the mailing list.

Stewart Bryant (SB) - Glad to see moving this to an Experiment, 
encourages focussing on IPv6 - glad to see narrowed scope so that it can 
work with MPLS, nervous about interaction with white cloud in the 
diagram. Can white cloud inject information that causes mis-allocation 
of funds?

Ted Hardie (TH) - clarifying question - are you asking that the charter 
do something to address this, or are you asking whether re-ecn addresses 
this? How re-ecn deals with this now is not relevant.

SB - Charter should clearly address the security risks.

BB - on the v4 vs. v6 topic - a number of people have thought long and 
hard about using up the last bit of the IPv4 header - difficulty is that 
sensible trials with real users and real applications need real traffic 
(don't mean to be rude about IPv6, but we won't get that there). IPv4 
code can be restricted in time and space.

AM - As a provider, why would I want to express that my network is 
congested? The use case should take that into account.

TS - Would your question apply to ECN?

AM - I'm not well-versed in the protocol.

MM - If you don't mark then remote senders will hit your network harder 
because you're effectively giving them permission to use a higher data 
rate, this signalling is how we tell senders to slow down.

AM - the use case needs to express this.

TS - It would be a burden if the experiment had to be conducted on a v6 
only network. It needs to be considered whether that burden needs to be 
put on this work.

LD - We need to balance need to have a runnable experiment versus 
concerns about burning the last bit in the IPv4 header.

DM - IPv6 networks as they're being deployed are smaller in scope, more 
experimental, more likely to experience congestion. If an experiment 
there can show a benefit versus IPv4 network that's a more experimental 
environment for operational traffic for operations folks at Verizon.

Mat Ford (MF) - It's hard to understand why people have difficulty with 
the idea of re-classifying the last bit in the IPv4 header to allow 
experimental use, when it is debatable whether IPv4 has a long life-time 
ahead of it.

LD - Perhaps another way of expressing that is to ask, do we reasonably 
project that in whatever lifetime IPv4 has there will be cause for a 
standards-based use of that last bit?

Lars Eggert (LE) - One proposal would be to initially limit 
experimentation under the initial conex charter to IPv6. We need to 
investigate how experimentation in IPv4 could proceed and be limited as 
necessary - make this a work item for conex. If that proves positive 
reconsider the limitation and potentially re-charter at that point.

LD - Certainly don't want to gate chartering conex on this point.

LE - It's clear that it should be possible to get useful data from IPv6 
experiments.

Mark Handley (MH) - We need to define how we know whether the experiment 
has succeeded or failed. The bit has to be redefined as experimental for 
anyone to make any use of it for anything, otherwise it's just a useless 
bit.

LD - Thanks all for your input. Revised charter will appear on the list 
in due course.

ENDS

-- 

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