[PCN] **DRAFT** IETF 76 PCN meeting minutes

[Steven Blake <slblake at petri-meat.com>]

Howdy.

The draft meeting minutes from Tuesday are attached.  Thanks to Philip for
taking them!

Please send comments/corrections to the list within the next week.


Regards,

// Steve

Congestion and Pre-Congestion Notification WG (pcn)
IETF 76 Meeting Minutes

CHAIRS: Scott Bradner <sob at harvard.edu>  (not present)
        Steven Blake  <sblake at extremenetworks.com>

Minute taker: Philip Eardley <philip.eardley at bt.com>

Tuesday, November 10, 2009
0900 - 1130 Morning Session I
Cattleya West
==============================================================================

AGENDA:

o Administrivia
  http://www.ietf.org/proceedings/09nov/slides/pcn-0.pdf  

Steven Blake presented the agenda slides, which were accepted without
objection.  He also reviewed the current milestone status.


------------------------------------------------------------------------------
o Encoding Comparison
  draft-ietf-pcn-encoding-comparison-01
  http://www.ietf.org/proceedings/09nov/slides/pcn-5.pdf

Steven Blake presented the slides on behalf of Kwok Ho Chan, who was not
able to attend.  Thanks to Kwok for his work on it.  Steven polled the room
to see how many had read the draft; few had.

Lars Eggert: It got added to the charter – so the people who wanted it added to charter are expected/obliged to review it.

Steven Blake: Want to go to working group last call before the end of year.

Philip Eardley: I have 2 comments that I think need to be solved before it is
ready for LC:
- It doesn’t give a good sense of why baseline was chosen
- It doesn’t give good sense of the pros & cons of various working-group 
  proposed extension encodings.

Steven Blake asked for the status of draft-ietf-pcn-3-state-encoding and 
draft-ietf-pcn-3-in-1-encoding. One of them (which?) is blocked due to a 
dependency on the ECN tunneling draft.

Bob Briscoe: ECN tunnelling draft-related encoding status – I think/hope that I
have resolved the blocking issues with David Black, so the draft should soon be
able to move forward.


------------------------------------------------------------------------------
o Signaling Requirements
  draft-karagiannis-pcn-signaling-requirements-00

Tom Taylor presented slides on the signaling requirements draft.  Credits – 
Georgios started, Michael, Kwok, and Tom worked on the draft.  The current 
draft doesn’t include the requirements for the piggybacking edge behaviour.

Tom Taylor: Last bullet of slide 3 – “not sure I agree with it!”.

Steven Blake: What is behaviour if the signaling channel breaks & how do you 
know if it’s still alive?

Tom Taylor: Admission state is sent regularly so reliability is less important 
– over-admit for say 100ms – but for flow termination, reliability seems more
important.

Tom Taylor: I don't understand why the slides say MAY for traffic rate 
reliably and MUST for flow id reliably – odd mix?

Bob Briscoe: The reasoning may be that there are other ways to do termination
e.g., incrementally terminate more & more flow until you leave flow
termination state?

Steven Blake: If you’re going to send one reliably, then sending the other 
reliably is trivial.

Philip Eardley: Requirements between ingress & centralised decision nodes are
missing.  Also question whether it is valid for the centralised node case to 
be in the draft given it’s really out of WG scope.

Lars Eggert: Not sure if centralised node case should be in.  The draft is to 
capture requirements for all signaling cases without prescribing one 
signaling solution. Would rather see this is in a centralised node edge 
behaviour, rather than in this draft.  

Tom Taylor: Yes, this would fit into a draft I wanted to revise.

Steven Blake: Possibly could do handle it with neutral "functional element"
language.

Philip Eardley: Not sure this would work.

Tom Taylor: Is this ready to become a WG draft?

Steven Blake: Draft has been read by a few people.  Please send comments to
the mailing list.  Then we can decide whether to become a WG draft; the 
question will be called on list.


------------------------------------------------------------------------------
o Controlled Load and Single Marking Edge Behaviours
  draft-ietf-pcn-cl-edge-behaviour-01
  draft-ietf-pcn-sm-edge-behaviour-01
  http://www.ietf.org/proceedings/09nov/slides/pcn-3.pdf


Tom Taylor presented slides on the Single Marking (SM) and Controlled Load (CL)
edge behaviours.  SM is billed as intermediate step to CL, so we are trying to 
keep them in step as similar to each other.

Tom outlined the history of the drafts – what is reported and when – and how 
this has altered between the versions of the drafts.

Philip Eardley: Even in the CL case, the info about the actual level of CLE is
valuable.

Philip Eardley: Reporting info about all the rates is not much different from 
reporting one bit, as it’s in one message.

Philip Eardley: Please can we confirm that we agree with this now, so we don’t
re-visit it again as though we agreed this last time.

No disagreement was expressed in the room.

Lars Eggert: Don’t pre-process data, raw info is good or better for use cases 
in the future don’t know about now.  Don’t cut off avenues. 

Bob Briscoe: If doing periodic reporting, have got to say when to stop, given 
most pairs won’t have any traffic on, so it's pointless doing periodic
reporting on them. 

Tom Taylor: This has implications for the signaling protocol.  Need reliable 
keep alive anyway?

Bob Briscoe: Some signaling between ingress & egress to clear down last flow?
Otherwise quite wasteful given most pairs don’t have any traffic.

Ruediger Geib: I favour simple solution but will not fight for it, as not 
interested in the RSVP style case.  I would like PCN without the signaling 
stuff; i.e., marking in core without signaling mechanisms at edges.

Tom Taylor: How can ingress find out what to block without signaling? Or will 
pkts be dropped at egress? Decision is enforced at ingress. 

Tom Taylor: Discussion isn’t tied to a particular protocol.

Tom Taylor: Summary/decision: we’ll signal raw rates for future flexibility,
etc.

Tom Taylor: Do we report periodically or try to optimise?  Engineering decision
– how frequently are thresholds crossed compared with periodic reports?

Lars Eggert: Periodically means fixed intervals for reliability. So a gap is 
assumed to mean loss. 

Steven Blake: Randomise slightly.  IETF historically against fixed intervals 
because messages can get synchronized.

Tom Taylor: Needs discussion on list.

Tom Taylor: Is smoothing essential or a detail left to implementation?
Question is switching between blocking & admit state – is smoothing here nice?
Simulations have been done with exponential smoothing.

Steven Blake: Drafts say parameters don’t matter. But we need to recommend 
something; e.g., “about ½” or “set to 1 is ok”.  Otherwise why recommend it?

Tom Taylor: Question of how quickly you react to stuff, and whether you can 
induce correlation effect by reacting too quickly.


------------------------------------------------------------------------------
o Piggybacking Edge Behaviour
  draft-taylor-pcn-piggyback-edge-behaviour-00
  http://www.ietf.org/proceedings/09nov/slides/pcn-4.pdf

Tom Taylor presented slides on the piggybacking edge behaviour.

Francois Le Faucher: For some signaling protocols, they’re receiver driven;
i.e.,  reservation request comes from egress side.  Have you thought about
this case?  The goal is a good thing.  See the old RSVP draft as source of 
info.

Not many people have read draft.  Potentially a WG item, after it is revised
to address Francois comment.


------------------------------------------------------------------------------
o Hose Edge Behaviour
  draft-karagiannis-pcn-hose-edge-behaviour-00
  http://www.ietf.org/proceedings/09nov/slides/pcn-2.pdf

Ronald in 't Velt presented slides on the HOSE edge behaviour.  The marking 
behaviour draft (draft-ietf-pcn-marking-behaviour-05) says that ETM-marked
packets SHOULD be preferentially dropped – which is not what the HOSE edge
behaviour wants.

Lars Eggert: Can’t update a standards-track document in an informational edge
behaviour document.

Philip Eardley: It seems dodgy to admit a flow if the signaling request is 
unmarked whatever the CLE.  This gives an incentive to send 1000s of request
repeatedly until one will get through.

Not many people have read the draft.

Steven Blake: Need discussion on list before making this draft a working group
item, but the behaviour needs to work with the agreed marking behaviour for
ETM-marked packets.  I believe that it can probably can be made to work.

Steven Blake: ECMP support - not safe to assume that path signaling message
will follow the same path as the data – so not safe to say that this
scheme solves the ECMP support issue.

Francois le Faucher: Is it desirable that, in case the network is marking 50% 
of packets, that we still accept 50% of new calls?

Steven Blake: Someone please send info to the mailing list.

Bob Briscoe: Status update on the ECN tunnelling draft in tsvwg: thinks issues
have now been resolved, but thought this before.  Then 3-in-1 can go ahead to
last call, etc.


Meeting adjourned.