Congestion and Pre-Congestion Notification WG (pcn) IETF 75 Meeting Minutes CHAIRs: Scott Bradner Steven Blake Minute taker: Andrew McGregor MONDAY, July 27, 2009 0900-1130 Morning Session I Room 300 ============================================================================ AGENDA: o Administrivia http://www.ietf.org/proceedings/75/slides/pcn-0.pdf Steven Blake presented the agenda slides. He noted that RFC 5559 (PCN Architecture) had been published. The agenda was accepted without objection. ---------------------------------------------------------------------------- o Encoding Comparison draft-ietf-pcn-encoding-comparison-00 http://www.ietf.org/proceedings/75/slides/pcn-6.pdf Kwok Ho Chan presented status of the draft, which has recently become a working group draft. Philip Eardly: Is it worth going forward with this draft? No significant changes since last revision, and it is now rather historic. Chan: I don't want to put too much more time into this, because it's essentially historic and done. Eardley: It seems to need a lot of rewriting, because much of the content is well out of date. Georgios Karagiannis: May be needed, because a) it provides motivation for some items and b) it's a charter item Chair: is there any discussion of ECN and PCN coexistence? Chan: Yes Eardley: There is discussion in the architecture, baseline, and one experimental encoding drafts. Bob Briscoe: The reason for needing these schemes is the ECN tunneling problem; solve that and many schemes are no longer needed, and therefore this draft also. Chair: This draft is historic. Another issue is coexistence of e2e ECN and PCN. Briscoe: I'm taking the ECN tunneling draft to the security area later in the week. Chair: Will raise the question as to whether this draft is still needed on the list; ask for feedback from the AD. Authors are encouraged to keep working on it. ---------------------------------------------------------------------------- o Marking Behaviour draft-ietf-pcn-marking-behaviour-04 http://www.ietf.org/proceedings/75/slides/pcn-3.pdf Philip Eardley noted that this draft is now being reviewed by the IESG after working group last call. No questions ---------------------------------------------------------------------------- o Baseline Encoding draft-ietf-pcn-baseline-encoding-04 http://www.ietf.org/proceedings/75/slides/pcn-1.pdf Philip Eardley noted that this draft is now in the Transport AD queue. A significant new item in the draft is that 'PCN WG will maintain a list of PCN compatible DSCPs' ---------------------------------------------------------------------------- o Experimental Encodings (3 State, 3-in-1, PSDM) draft-ietf-pcn-3-state-encoding-00 draft-ietf-pcn-3-in-1-encoding-00 draft-ietf-pcn-psdm-encoding-00 http://www.ietf.org/proceedings/75/slides/pcn-1.pdf Philip Eardley reviewed the status of each of the three experimental encoding drafts, which have recently become working group drafts. Karagiannis: Affective marking may be possible in the basic 3 State scheme. Would like to see some text added to that draft. Chair: Might need a draft. Karagiannis: Would like to see comparison between the use of the router alert option and PSDM in some draft. Chair: Ask Chan Chan: I'd like to second Bob's comment: if the tunneling draft goes ahead, many of these issues will be clarified. Hopefully in a few days there will be a better picture of that. ---------------------------------------------------------------------------- o PCN experiments - working group next steps Eardley: Do we want to take forward all four encodings to RFC? Chair: We don't want to put too many experimental RFCs forward, the IESG is unlikely to approve more than 3. The presently documented encodings are the ones on the table. Eardley: If the tunneling behaviour is sorted out, then 3-in-1 becomes the preferred option, unless someone really wants end-to-end ECN support as well. Unclear if end-to-end ECN is somewhat theoretical at this point, or a real option. Chair: Transport AD Magnus Westerlund has a draft on the use of e2e ECN + PCN for RTP in the AVT working group. Gory Fairhurst: Briscoe's ECN tunneling draft is being presented in the tsvwg for certain. Chan: There's been previous work on marking... what do we do with previous findings, are we going to put those findings in our documents? Chair: Right now we have two informational edge behaviour drafts, experiments also cover PCN marking and edge behaviour. Chan: PSDM simulation experiments have been done, inquiring about bringing some of those results into future experiment reports. ??: Probably best not to wait for all of these experiments to start at once. Also, having a dependancy on Bob's tunneling draft seems to be an issue. Eardley: 3-in-1 encoding has little point without the ECN tunneling draft being accepted, except if an operator can ensure there are no tunnels in the PCN domain. Briscoe: It would be best for all document authors to declare if they depend on the ECN tunneling draft, or if they would abandon work if it proceeds. Karagiannis: In favour of the the extended 3-state draft (draft-ietf-pcn-3-state-encoding-00), where PCN supports the end-to-end ECN concept, along with the 3-in-1 draft (draft-ietf-pcn-3-in-1-encoding-00). Eardley: Sounds like we should go forward with 3-in-1 and extended 3-state drafts. Chair: The baseline draft has 2 encoding states, and we'd like a 3-state alternative if we can come up with one that works. Fairhurst: An experimental draft that is intended to progress should document why it is not on the standards track. Eardley: Many experimental RFCs don't document what the experiment was. Fairhurst: That can't be too hard. Chair: If a draft advances to RFC, it has to get WG consensus, so it should document its purpose. ---------------------------------------------------------------------------- o Performance Evaluation of CL Termination draft-satoh-pcn-performance-termination-00 http://www.ietf.org/proceedings/75/slides/pcn-4.pdf Daisuke Satoh presented the performance results of experiments performed using the Controlled Load edge behavior. Karagiannis: I think over-termination has also been discussed in the LC-PCN draft, where a sliding window is used and some other countermeasures are proposed. Eardley: I think the LC-PCN draft was talking about a different issue, but this is probably mailing list material. The important thing appears to be that we have found this effect and can avoid it, by delaying a second round of terminations. This does need to be added to the edge behaviour drafts, as more specific advice. Anna Charny: In simulation, the range of over-termination seems to be limited; so the question is, to what extent do we wish to address all the many causes of over-termination, or do we just live with occasional over-termination? Chair: This should perhaps be noted for the PCN-CL draft, since it is probably unreasonable to cover every possible over-termination scenario. Chan: Looking at simulation results, there are differences between marking behaviours, so this brings back the notion of revisiting those simulations as guidance for next steps. Charny: These issues are also pertinant to the Single Marking (PCN-SM) draft. Briscoe: Anything that is trying to do termination in one shot is going to overdo it in some cases, partial termination is likely to be more accurate. So the trade-off is, speed or accuracy. You probably would not want to start terminating flows if you see only one excess packet, so you wait ... and then, how quickly do you act? May be a call for the operators. ---------------------------------------------------------------------------- o Controlled Load Edge Behaviour and Single Marking Edge Behaviour draft-ietf-pcn-cl-edge-behaviour-00 draft-ietf-pcn-sm-edge-behaviour-00 http://www.ietf.org/proceedings/75/slides/pcn-5.pdf Tom Taylor presented the status of the PCN-CL and PCN-SM drafts, which were recently posted as working group drafts. Chair + Karagiannis: There are examples of how to do Ingress-Egress aggregate identification in the PCN architecture RFC (5559). Charny: Would 30-packet estimation only be an issue for low-speed aggregates? Taylor: If you have a low volume aggregate and are receiving congestion markings, there is no real urgency? Charny: This seems only to matter a lot for very high volume aggregates, and so estimation error for the low volume ones is not a large issue. Eardley: I don't understand the benefit of smoothing? Taylor: Probably faster is better, in that otherwise you run a risk of QoS degradation for a time. Eardley: One disadvantage, is if you get slashdotted, you might miss the opportunity to mitigate load. Taylor: Exponential smoothing gives delay and/or overshoot. Briscoe: Does oscillation matter? It may just be variation, as in the load is variable, so it may not need smoothing. Taylor: Repeated attempts causes thrashing. Briscoe: So, try to block that as close to the user as possible. Charny: I'm a bit unsure what the question about smoothing is. Simulations assume certain behaviour, are we trying to address any behaviour from those simulations, or what? Taylor: It does come back to the simulations. The question is, how much smoothing is desirable in the system, modified by the potential for oscillation, and does that matter? Eardley: There is a measurement period in PCN-CL, which amounts to smoothing. Taylor: Reaction times on the order of a second. Is a second too long? Eardley: Period can be shorter. Chan: Earlier work, time period between admission control and termination are separate. Hence two level control, and an attempt to operate between the two levels. Taylor: We want not to be overly sensitive, i.e., if there is too high a probability of oscillating into the termination zone, the system should be less sensitive. Charny: From the last IETF meeting to this one, did the edge behaviour drafts change measurement behaviours? Taylor: No, only reporting. Charny: The initial drafts strictly corresponded to the simulations. Are we changing that? If not, then there is no real issue, but if so, then we need to clarify why and how does that effect previous results. Taylor: I don't think there's a change. I will check. Eardley: The change between simulations and this draft is that simulation did per-packet EWMA smoothing, whereas the draft does interval measurement. Charny: Lets discuss this offline. Taylor: Will prepare examples. Chair: Please take this offline. ---------------------------------------------------------------------------- o WG next steps Chair: Let's discuss the next steps for the working group, excluding re-chartering. Who is going to write the missing documents? Eardley: Not to answer that directly ... regarding the Requirements for Signalling milestone, is that something we should be thinking about when writing the edge behaviour documents? Charny: Both edge behaviours have a section on information necessary to transmit, so when we talk about signalling, is it merely that or something more? Chair: What is the protocol for that and when does that signalling happen? Charny: Is it a standalone document, or is it already part of the edge behaviour drafts? It isn't going to be one document, but one per edge behaviour? Chair: Charter assumes it's standalone, but if different edge behaviours require different protocols, better to discuss this on-list regarding where to put the documentation. Especially given that we have two edge behaviours. Charny: The edge drafts have diverged; same data but different timing of signalling. As originally written, it would be the same, but that has now changed. So, where does this get specified? Chair: That's an AD question, so let's take it up with Lars Eggert. Karagiannis: A point of discussion: I am prepared to work on a requirements draft with Tom Taylor. Briscoe: To clarify Anna's comment on timing: better phrase might be interaction model. For admission, there is two models: no start without signalling (sync), or gate starts against egress threshold (async). Chair: When charter was written, assumption was that PCN signalling was orthogonal to admission signalling, and this seems to be written into the charter. May need to revisit. Taylor: If you do have resource signalling, I see no need for altering that signalling, the egress signals no resources available, this is not PCN specific, it simply uses PCN for measurement. Termination is a separate matter. Chair: ADs seemed to assume that PCN signalling would be separate from admission/termination signalling. Question is, do we want to specify a PCN-specific protocol for signalling from egress to ingress, and that seems to be the charter point. Taylor: If you're piggybacking, no encoding is required. Only in the async case is explicit signalling required. The ITU architecture for PCN has a DIAMETER-based protocol for this sort of signalling. Briscoe: I don't think anyone is talking about a new signalling system for this. More, this is about an async message for whichever system is in use. Chair: Presuming we're not required to make a specific protocol. Briscoe: Please, let us not do that. Let's add them in to another signalling protocol, whatever is in use in the domain. Chair: Let's ask the AD. Briscoe: Lets use existing systems for this wherever possible. Charny: What is the place to specify signalling, and is there a requirement that these mechanisms are uniform for edge behaviours; this constrains how the drafts are written. Karagiannis: We should identify common edge behaviour requirements. Also, lets emphasise that if existing signalling can possibly support what we need, we should use those. Chair: We don't assume external signalling explicitly. Chan: At the very beginning, we did not assume reverse signalling, egress behaviour alone may be sufficient. Could not some of the admissions be decided at egress? Signalling may be unnecessary. Charny: Simulations do assume egress-ingress signalling. Chair: There have been drafts that did assume egress control behaviour, but the PCN-CL and PCN-SM working group drafts don't assume this. Briscoe: I was saying that PCN does not need to invent a signalling protocol, although possibly messages for one. Taylor: Reliability is an issue. If you design a signal in system X, you need its reliability behaviour as well. Briscoe: That's why you should use something existing. Also deals with discovery, addressing, etc. etc. Chair: Charter is two years old, so it probably needs clarification. Requirements draft needs to be written ... not necessarily proceeding to RFC, but as a discussion point. So, Georgios and Tom, please proceed. ---------------------------------------------------------------------------- Chair: The working group is close to wrapping up its initial charter requirements. Will inform ADs. Meeting adjourned