-----------------------------------------------------------------------
IETF 80 
CONEX Meeting
Minutes 
-----------------------------------------------------------------------

=== Status of the Working Group

Nandita:
Missed Feb 2011 milestone for use case description
Use cases: needs significant work on content and editorial
Abstract mechanism draft: in good shape but has rough edges
Other charter options:
Marking in v6 packets: need to choose viable option
Modifications to TCP: hoping to start soon

=== Bob Briscoe
Congestion exposure concepts and abstract mechanism
http://www.ietf.org/id/draft-ietf-conex-abstract-mech-01.txt

Bob:
Matt Mathis is not here
This draft has to go through IESG after use cases
Context: informational doc, has had some comments
Goal is to define requirements for encoding (how many states, what 
features need to be)
Scope: SHOULD include loss-based and ECN-based deployment
Scope: not just for TCP
Review of how mechanism works
Draft improvements:
--Text on what conex is not: point is not for routers to do congestion
 control; may need to keep adding more items that conex is not
--Rationale for the credit signal: flow needs to start with credit so 
network doesn't have to understand RT time

Mirja:
If you want to be conservative you need as many credits as packets in 
flight. If not, what do you do with credit? Should this be in the draft?

Bob:
Should be in the draft. Idea is to give incentive to CC designers not 
to overshoot at the start. Should recommend something in TCP draft for 
standard TCP. In Linux implementation there are attempts to answer this 
-- differs by implementation.

Mirja:
Should document the overshoot, all draft says is that credit makes audit 
function simpler.

Bob:
Agreed.

Georgio:
Audit function described as being able to count packet loss.

Bob:
That's just one possible audit function.

Georgio:
Policer isn't mentioned, won't have ability to count lost packets.

Bob:
Right. But it's much less necessary to say what the policy function is 
than the audit function.

Georgio:
But what policer does is compare sender congestion to actual observed 
congestion?

Bob:
The policy device compares whether the traffic is in its policy, 
doesn't look at observed congestion.

Georgio:
Sender will detect losses, knows real congestion rate.

Bob:
Taking this offline. Onward...

--Change to TCP ECN feedback: feedback is more generically useful in 
TCP for purposes other than conex; suggested that we have a definition 
of generic feedback and then use generic in the conex TCP draft

Marcelo:
Which draft are you talking about? The TCP draft(s)?

Bob:
Yes

--Added section on audit function with normative text about audit 
behavior
--Added monitoring against policy function as the most generic 
function: capacity upgrade, penalties, charging, warning --> all 
have monitoring as fundamental element

Behavior constraints for audit function
--Minimal false hits
--Minimal false misses
--Transport oblivious
--Sufficient sanction (even against tradeoff attach between 
policer and auditor)
--Non-vulnerability to memory exhaustion
--Non-vulnerability to identifier white-washing (recycling IDs)

Minor modifications

To Do List
--Propose new section about partial deployment: 5 aspects
	1 conex and/or non-conex packets
	2 conex and/or non-conex receivers
	3 interwork with loss and/or ECN queues
(these first three just need pointers to other docs)

Mirja:
Do you talk about conex receivers in the draft?

Bob:
Talking about these new feedback receivers.

Mirja:
Conex should be sender-side only.

Bob:
But having receivers is more optimal. Could say a TCP conex 
must support SAC if you're going to use conex.

Mirja:
In abstract mechanism don't want to require receiver changes.

Bob:
Would be in TCP draft.

Nandita:
Partial deployments section also exists in use cases draft, 
what's the different?

Bob:
Will answer. But two more types of partials:
	4 some networks use conex, others don't (e.g., as 
          discussed in use cases draft)
	5 other non-e2e arrangements (e.g., proxy as 
          described in draft-kutscher)

Dave:
Is non-conex customer attachment covered in #1 or #4?

Bob:
#1

Someone:
If we want to support #3, then should have requirement that 
sender/receiver can count rate of lost packets.

Bob:
Probably true, but we haven't documented that.

Someone:
In reliable transports like TCP and conex-marked packets are 
lost, does conex signal get retransmitted?

Bob:
That goes in a transport-specific draft. But do need to say 
something about interaction between loss and ECN.

Someone #2:
Let's say packet gets ECN marked and re-feedbacked. Somre routers 
can do DPI and know exactly what happened, so why do we need this?

Bob:
It's the other way around -- mechanism is designed to allow policy 
device to deal with packets without having to know what they are, 
without needing DPI.

Status and PLans
--more about what conex is not
--more ascii art
--new section on partial deployemnt
--interaction betweeen ECN and drop
--get wider review
--could then go to WGLC? aim for July

Marcelo
When will it be ready for WGLC?

Bob:
Hoping to have edits done in next two weeks.

Nandita:
That's ambitious.

Nandita:
Why do you need re-echo-ECN and re-echo-loss? What if you combined 
them, what are the tradeoffs?

Bob:
Matt thought this was important. Loss easier to do near source, ECN 
easier to do near destination, so conflating them makes both difficult 
to do. I disagree but not enough to take it out. Might have to do it 
to fit into less bits though.

Nandita:
We need to align terminology between the two drafts? IS it aligned now?

Bob:
Haven't checked.

Nandita:
That's another action item then.

Phil:
In #4 of partial deployments, can't just refer to use cases because 
some stuff will have protocol implications, auditing against the 
bottleneck, so needs to go beyond use cases.

Bob:
Right. Don't want to put mechanism stuff in use cases. Will have some 
text about each partial deployment scenario.

Mirja:
Not sure if we want to go to WGLC early, before we do TCP draft.

Marcelo:
WGLC is just for wider review, doesn't mean we're going to ship it 
right away.

=== David Mcdysan and Bob Briscoe/Richard Woundy
Conex concepts and use cases
https://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/

Dave:
Status of changes requested at IETF 79
--removed mechanism description
--removed DDos mitigation
--added use case about inequity of usage in long timeframes
--revised congestion terminology: new definition includes delay, 
different from mechanism draft, so need to work that out on the 
mailing list; need to narrow in on definition of congestion
--changes not yet addressed:
	--clarify differential qos use case
	--flesh out operator perspective but avoid discussion of pricing

New section on longer timescales in -01
--list discussion recommend split into two use cases: 1 longer time 
scales, 2 shapers/self-congestion and go-faster requests
--merge longer timescales into 5.1 text on traffic management
	--heavy vs. light users
	--summarize longer time scales
	--need to clarify terminology: policer, shaper
--may remove detailed example from section 6.2

Georgio:
Would shaper be able to identify each flow to shape specific traffic?

Dave:
No, traditional shaper as described for DSLAMs. It's not conex aware, 
it already exists.

Georgio:
But then if it shapes all traffic, conex rate might be affected.

Dave:
It doesn't treat conex packets differently from non-conex packets 
because conex doesn't exist yet.

Georgio:
But conex will be affected, e.g., for audit.

Dave:
If it's downstream from the shaper. Relates to the mechanism description.

New items from mailing list
--Handling shapers and self-congestion: Stuart Venter's "go faster" 
concept, some discussion added to section 1 in the -01 about self vs. 
inter-user congestion
	--Does WG want to drop the "go faster" concept?

Mirja:
Shapers: use case is that if conex is there, you don't need a shaper 
anymore, and since you don't need that, you don't need "go faster," 
you just ask for more conex credits. But even so, this would be on top 
of the conex signal. Not in scope right now.

Dave:
Service provider still wants to do shaping could use conex to adjust the 
rate of the shaper.

Rich:
For "go faster," we already have PowerBoost working off a token bucket 
in a policer. So argument could be made that if you have conex, then you 
could create a larger boost size. Implication, not a direct connection.

Dave:
Will continue discussion on the list.

--Other ways to incentize LEDBAT that aren't in current draft

Nandita:
Continue the preso. As individual contributor, haven't seen consensus on 
the mailing list about the new section 6.

Bob:
Partial deployment proposal
--start assuming conex first deployed on sender: incentive for 
low-congestion-causing users to declare their low congestion-volume
--pointers to each aspect with brief explanation
	--repeat same list of 5 pointers from mechanism draft
--for case #4:
	--describe basic idea where network can protect its network segment
	--explain what networks do with non-conex traffic
	--finish with charter scenario as an example

Phil:
Will you refer back to use cases in the partial deployment section?

Bob:
Two types of use cases: how you use conex and how you arrange networks

Mirja:
Where will it be in the draft?

Bob:
Where it is now

Alissa:
Don't call them both use cases. Have already had confusion. Separate deployment 
configurations from use cases and put them in separate sections.

Dave:
To Do
--address open items from list discussion
--have WGLC on revised draft

Marcelo:
Draft is moving backwards. Chairs are going to think about what next steps are, 
but these are not them.

=== Suresh Krishnan
An update on IPv6 options
http://www.ietf.org/id/draft-krishnan-conex-ipv6-02.txt

Suresh:
We were naive in expecting to change something in v6, now looking for least bad 
option.

Requirements for marking IPv6 packets
1 visibility
2 traverse nodes that don't understand
3 immutability
4

Candidate solutions
extension headers, hop-by-hop, dest opts, bits in v6 header (flow label)

Bob:
We're not talking about routers doing anything with conex, we're talking 
about policy functions in router.

Suresh:
I meant intermediate nodes, not routers.

Extension headers
--not hop-by-hop
--not incrementally deployable; nodes drop ones they don't understand 
and send ICMP (even though they shouldn't do that, they do, e.g., firewalls)
--other two reqs are fine

Hop-by-hop
--packet cannot be processed in deterministic time, so router vendors either 
drop, rate-limit, or push it to the control plane (slow path, 2 orders 
magnitude smaller)

Destination Options
--RFC doesn't use 2119 language -- probably not legal to inspect in intermediate 
node but we could assume otherwise
--only option that may be palatable to 6man

Header
--no one wants to give a signal that v6 isn't done, so there are no bits for us

Eric:
DSCP is legal in the header

Suresh:
Dest Options
IPSec means dest options will not be visible to intermediate notes

Andrew McGregor:
Reasonable to use dest options outside IPSec and ESP, pass it through, then copy 
it inside like ECN

Suresh:
But in 2460 they have a recommendation without 2119. Implementations I've seen 
assume that dest options will be on the inside.

Brian Carpenter:
Read the RFC as if it's written in English. If it says recommended, then take 
it like should in English.

Marcelo:
So we can use dest header outside ESP?

Brian:
I'm not denying it.

Andrew:
Key question then is how many ESP boxes will freak

Dave:
Refinement of your requirement 3 . . . (missed this)

Suresh:
So we can write up a draft using destination option and wait for 
the semantic of the bits

Marcelo:
Implication that we're misusing dest opt but this seems to be 
the lesser evil.

Dave:
Earlier question re flow spec and DSCP -- are we covering those?

Marcelo:
My understanding is that 6man is not going to give us flow label.

Ken:
Draft exists defining a header for flow handling that uses all the bits

Brian:
Author of the draft -- 20 bits with no semantics, not intended to be 
micro-coded

Mikhail:
Wouldn't all routers have to be conex-aware?

Marcelo:
Dest options are only looked at by final router. We're requiring 
conex-capable intermediary node to look at the header.

Bob:
Mikhail's understanding is different. If we use dest options, we should 
somehow formally get 6man to note that v6 is broken and inextensible.

Marcelo:
Have a symptom here, but I don't think we have the energy to change this, 
so let's be pragmatic.

Suresh:
Protest note in the draft.

Andrew:
RFC 2460 says it's legal to have dest option before ESP

Suresh:
Yes, for source routing nodes. Only for that subset of dest options.

Andrew:
Yes, need other dest option to be processed.

Suresh:
Then need routing header.

Andrew:
Just put same decapsulation header on outside and inside.

Mirja:
Does receiver then have to be conex aware?

Andrew:
Decapsulator has to be conex-aware.

Mirja:
Change to IPv6?

Andrew:
No, change to ESP, not to IPv6.

Suresh:
We do the changes and see how ESP support goes. 

Andrew:
If conex-aware node is running ESP, then it's ok, but that may 
not be the case.

Marcelo:
Objection to destination option?

Bob:
Wait and see what experiments find. Try to see whether using the 
destination option will work first.

Marcelo:
Who will do this experiment?

Suresh:
What do you do if the experiment fails?

Marcelo:
That is valid input if someone is going to run the experiment.

Mirja:
So you have to implement a conex-aware router?

Andrew:
MPTCP have done a bunch of experiments already

Mirja:
Is experiment to put header in packet and see if it goes through 
a router?

Marcelo:
It's how hard it is to look at destination header, how does it 
interact with IPSec? Does the node crash?

Mirja:
Do we need a vendor? Should the spec of the router tell us this?

Marcelo:
Can fabricate the IPSec part and see what happens.

Andrew:
Looking at options on intermediate nodes isn't a difficult thing to 
do. Current switch silicon could do conex counting with no 
performance cost.

Marcelo:
Only question we have is how this intersects with IPSec

Bob:
Retracting my question about the experiment

Marcelo:
Objections to going forward: No hands
Best way forward: About 15 hands

Tekka:
General destination option or conex destination option?

Marcelo:
We need to define the option.

Tekka:
This could be a general destination option

Wes:
Good to use dest opt now. Wonder if we need to ask 6man to make 
hop-by-hop options processable by intermediate nodes.

Marcelo:
But we wouldn't want every hop to look at this information.

Wes:
True

Suresh:
Hop-by-hop is not useful anyway because vendors just don't implement 
it because it's loosely specified

Wes:
So there's nothing we can do to make v6 extensible?

Suresh: 
No

=== Dirk Kutscher
Mobile Communication Congestion Exposure Scenario
http://datatracker.ietf.org/doc/draft-kutscher-conex-mobile/

Scenario where end hosts and network containing dest hosts are 
conex-enabled, fits well for mobile networks, have need for resource
management

Mobile congestion
--tend to think of congestion as non-issue bc resources are managed, 
best effort traffic was considered expendable
--data upsurge = inconvenient news

Shared resources in LTE
--access is not only consumer of resources, cells actually 
concentrate traffic in backhaul, core
--EPS bearers: QoS approach to managing flows (statically configured)

More resource management
--Traffic offload: avoid tunneling best-effort traffic in gateways, 
home nets
--3GPP chartered to add DPI to policy framework, already exists in 
most networks

Assumptions
--So mobile isn't really different -- just capacity sharing
--static differentiation between BE and important traffic isn't useful

Draft
--Describes 3GPP's EPS
--Analyze how use cases from draft apply to mobile
--How to get conex in EPS: across domains or single domain, policing, etc.
--Implications for conex to think about

Implications
--consider dynamic paths: change when you run out of credit
--requirements for fine-grained resource control
--tunneling
--traffic offload:
--roaming
--IPv4?

=== David Mcdysan
Usage/Volume Tier Feedback Use Case for Congestion Exposure
http://www.ietf.org/id/draft-mcdysan-conex-volumetier-usecase-00.txt

Policer token bucket meter on congestion marked signals
--could count them or drop them
--usage counters could be used

Probe case
--again building on top of conex

More generic information feedback concept on a longer time scale and 
without starving for bits in v6