Congestion and Pre-Congestion Notification WG (pcn) IETF 70 Meeting Minutes Monday, December 3, 2007 Vancouver, BC, Canada 1740-1950 Afternoon Session III Salon 2 ==================================== CHAIRs: Scott Bradner Steven Blake Minute taker: Tom Taylor AGENDA: o Administrivia chairs 10 min ------------------------------------------------------------------------------ - Blue sheets - Scribe - Agenda bash - Milestones status Steven presented on the working group status. Sees open issues on architecture doc -- not yet ready for WGLC. Need document for second milestone. Want one marking and encoding solution. Reviewed premises of work ("Why we are here") Chairs' assessment: get off the corner cases. Want single solutions particularly in the interior, to prevent interoperability nightmares. We have previously interpreted "inelastic flows" too narrowly. Need to be compatible with ECN and Diffserv. Need to speed things up. Operator feedback: moving in right direction, don't use too many IP header codepoints, hurry up so we can look at multi-domain Comments: --------- Anna: Have to be careful not to jeopardize multi-domain solutions. Scott: can't know everything. Keep interior marking simple, leave innovation to the edges is a proposal toward long-term validity. o Discuss open issues in draft-ietf-pcn-architecture-02 all 75 min ------------------------------------------------------------------------------ Philip: summary of progress and open issues. Joe: doesn't understand scenario where tunnel terminates within a PCN domain. Philip: more general scenario of tunnel into Diffserv domain. Joe: would we not use same protective mechanism as for Diffserv. Philip: basically same mechanism, but needed a little adaptation. Joe: but seems more reasonable to do at edge. Steven: RFC has tunnel end treated as ingress point to network. Michael M.: don't worry about this unless operators say it matters. Scott agrees. Tina: probing should be based on single message, signalling reqts dealt with in a separate draft. Steven: Probing advocated for two situations, ECMP and small aggregates. Small-aggregate reason is in his view a corner case. ECMP is interesting. Would be nice to have simple solution to that problem. Lot of security issues to probing. Imposing special reqts on router not a great way to go. AS Chair: this is where we make the decision. Michael: RSVP Scott: is there an RFC on ho to do do this? Magnus: Francois: Two drafts coming out. PCN is a different problem from the general RSVP problem. Michael: RSVP could be used to trigger admission. Anna: security one issue. Applicability of RSVP another. Issue on list was whether RSVP gives right info for ECMP case. Steven: certainly deployments where RSVP supported on ingress and egress, could then do PATH, RSVP use of PCN markings. Not in scope of PCN itself. Xiaoming: option packages dangerous for inter-domain. Elwyn (IAB view): concerned with time required to do admission control if you probe. Beginning to have serious issues with connection delay. Also concerned about trying to make external decisions on what happens on a single link. Bob: BT analyses show will get same result for repeated probes -- get time correlation, so single probe enough. Elwyn: even first probe raises issue of connection delay. Bob: in some cases can probe in parallel to signalling. Lars: what do you do with the remaining packets of a data flow that arrive while you are deciding to admit? Another issue, what impact does probing have on overall architecture. Jozef: UDP -- no feedback. (Questioned by ADs) Anna: is this a binary decision? Lars: any other way to handle ECMP? Bob: in some scenarios, don't need probing -- e.g. MPLS Anna: Steven: inconsistent to assume operator is competent to use PCN but not competent to engineer ECMP correctly. Steven: also have to think about reverse path with probing. Philip: BT has been thinking about ECMP for a while, but has failed to come up with an elegant solution. Can't predict that such a solution will emerge in next 6 months. Lars: would like to proceed without, see if any operator says it's critical. Anna: ECMP problems likely to be fixed independently. Steven as Chair: Egress discovery - is there any scenario where probing is the only way to do it? No answer. How many think we need to work on probing? ??: should be hashing Michael: not important to work on probing now, but should keep aware to allow extensibility. Scott: what needs to be in the architecture doc? How many people think we need a discussion of probing in the arch document? Kwok-Ho: question on RSVP -answered. Francois: simplicity means lowered usefulness. Jozef: matter of deployment scope whether probing should be discussed. Scott: this is an overall arch doc, what level of discussion called for Jozef: reasons for probing, not solutions ??: optional component of arch Anna: is current discussion OK? Steven: does there need to be discussion? A number of "yes". How many find current discussion necessary and sufficient? Again a number of "yes". Finds a significant number of people supporting this latter view. How many think protocol work on probing should be done right now? No one. Lars: how many think it should be done before arch draft WGLC? No one. Centralized decision-making node: Steven: is this something we need to work on? Anna: two questions -- should it be mentioned, should WG work on it? Discussion: differing views. Recognition that centralized node does not ncessarily mean new protocol. Steven: consensus that current text is sufficient on the topic. Addressing issue -- peer discovery. Philip enumerates a number of alternatives, will expand text. ECN: ---- Bob spoke in favour of classifying ECN as non-PCN Magnus: prefers ECN-compatible solution Michael: two different behaviours Discussion of whether all routers in the domain are PCN-capable. Jozef finds that unrealistic. Lars: charter assumption. Scott: matters only for routers that will experience congestion. Lars: scenario where e2e ECN would be beneficial would also be one where PPCN can help Magnus: Anna: discussion should really be informed by outcome of encoding discussion Steven: some algorithms would Lars: prefers coexistence Bob: endpoint based measurement doesn't work in some cases Magnus: trying to run below application level Steven: need more work in arch draft on ECN. Let discussion continue on list. Maybe encoding comparison will provide guidance. Philip: this is the last issue, as he sees it. Any other views? No reply. o Discuss open issues in draft-chan-pcn-encoding-comparison-01 all 45 min ------------------------------------------------------------------------------ Kwok-Ho presenting. Series of questions to simplify draft. Bob: can't see how PCN would work w/o using Diffserv codepoints. Steven: assumed that Diffserv would be used Jozef: redefine RFC 3168? Lars: really problematic. Jozef: suggested possibility: redefine behaviour of DSCP codepoint Kwok-Ho: bottom line: WG would register new DSCP codepoint with IANA. Scott: Diffserv codepoint assignments are based on Standards Track actions. Bob: thought Diffserv used locally-defined values. Anna: answered questions on slide. First two bullets, yes. Bob: trying to clarify intent of questions. Noted that whether Diffserv codepoint is used is different question from whether new codepoint should be standardized. Bob: on second bullet, replace 3.2 with para or two on how it would be impossible to do without Diffserv. Kwok-Ho: third bullet -- can out-of-band channels be eliminated from further consideration? Anna and Scott: rather than throw it away, say it will not be considered. Next chart: what indications are required. Drop Nonce indication. Agreed. Jozef: Anna: identify states. Steven: can't see fewer than three markings needed, or more than four. Philip: spoke for transition indications ??: Steven as contributor: have the draft concentrate on encodings -- where do we get the bits from? Other work can provide semantics. Discussion of whether DSCP visible end-to-end -- battle in Diffserv -- customers vs. operators. Philip: Need to say that range of states required is 3 to 5. Agreed. Next chart: criteria: Leakage-safe could be an additional criterion -- RFC 4744 Timed out. Take question of whether this is WG item to the list.