Dispatch IETF81 ================ Monday, 09:00-11:30, Quebec City Chaired by: Cullen Jennings and Mary Barnes Notetakers: Jonathan Lennox and Christer Holmberg Jabber Scribe: Adam Roach Conclusions: 1) Session-ID: WG interest to charter this work(mini-WG). Will proceed with refining charter. 2) Load Balancing: WG interest in this topic, but the motivation and exactly what (standards) work was required was unclear. Some work may be appropriate in the IRTF. Further refinement of the motivation, consideration of engineering aspects and continued discussing on the mailing required. 3) Global Service Provider Identifier: WG is in support of creating a URN for this. Document(s) likely to be AD sponsored. Discussion should move to RAI area list (as opposed to DRINKS or DISPATCH). 4) BFCP for UDP: WG interest in chartering this work (mini-WG). Group neutral as to whether the document should be informational or standards track Will proceed with detailed charter proposal. Link to audio file at: http://www.ietf.org/audio/ietf81/ietf81-205abc-20110725-0855-am.mp3 Link to Meetecho full multimedia recordings (including jabber): http://ietf81.conf.meetecho.com/index.php/Recorded_Sessions ====================================================================================== Detailed Notes (Jonathan Lennox): ---------------------------------- Dispatch WG -- 25 July 2011 WG Status Deadlines are remarkably soon, 5 weeks from today Other meetings of interest: RAI Area, CLUE Gonzalo: RAI Area meeting will discuss process for bringing work for RAI Area Presentation: Salvatore: End-to-end session ID Call-ID doesn't get through B2BUA Want to monitor/debug a session that goes through a B2BUA. James Polk: There's not just one use case, we're solving for multiple use cases, monitoring is not the only thing Salvatore: I know all the uses cases, but if we discuss them all from the beginning we'll never get chartered Cullen: Put words into the charter about what the identifier means; the proposed charter covers a bunch of use cases, but would require rechartering to cover all of them. James Polk: the charter doesn't mention monitoring, it mentions a bunch of other use cases Cullen: what we'll be deciding on today is the charter, not what's in the slides or the existing drafts. Back to presentation: difference between Call-ID and Session-ID, who guarantees Session-ID will not be modified, requirements Charter proposal Dale Worley: I want assurance that if we fulfill all these requirements, SBC Vendors will not need us to re-write this for privacy reasons. Hadriel: I can't guarantee this, we might need to remove it for all sorts of reasons, e.g. to interoperate with broken implementations, but the goal is to make them as benign as possible, and these requirements seem to achieve that Sohel Kahn: From an operator perspective, some transparency is good, but some opaqueness is necessary. Jon Peterson: I can understand there are circumstances when people need an end-to-end ID, but what requirements does this satisfy that Call-ID doesn't, in those circumstances are willing to pass the identifier? Salvatore: There are cases where Call-ID will survive, but plenty of cases where it won't. Andrew Allen: I think we're dealing with a legacy problem. The idea of a B2BUA is that you have two separate dialogs. Also, early on people put things into Call-ID that revealed privacy, so boxes are removing them, and the deployed base is going to keep doing that. But a real end-to-end identifier is necessary, so we need to charter this work. Robert Sparks: You seem to have a pretty good idea of what this "session" thing you're identifying is, but everyone I talk to has a different idea of what it is, and I think we need to converge on what it is. It has the "same aim" as the dialog identifier in the charter, but I read in the list discussion that people want to change the session identifier as part of the call. ?: People want to add it when the UA doesn't provide it Cullen: this charter is something that maps one-to-one to dialog IDs, but there are uses cases are very different than that. Robert: E.g. can you decide you need a different session ID in the middle of a call? E.g. if a call is transferred, is it the same session? Salvatore: We decided to start with the very basic use cases. Paul: This isn't one-to-one with a dialog-ID, in either direction. It's a bigger thing, made out of dialogs, that looks like a dialog when you cross your eyes. It's straight forward when you have two ends, with various things in the middle, but if you have more than two ends (either simultaneously, for a conference, or in sequence, for transfer) it's a lot more complicated. Cullen: my idea was that this would be dialog-ID if all your SBCs were proxies, that doesn't solve all the use cases, but every time we've tried to expand it we haven't had consensus. Adam Roach: even if this is clear, does it actually satisfy anyone's use cases? Whenever I've talked to anyone, it's like the supreme court's definition of pornography, "I know it when I see it". Hadriel: if the charter is unclear, please explain how you would like to clarify it. We can't use them because of B2BUA. Sohel: we also need it for SIP/H.323. I like the draft. Robert: There are things in the draft that aren't in this charter. Robert: Given the text in the charter, it seems like it can't be in an INVITE, has to be added later. If you were in a network that didn't have any Call-ID rewriting boxes, would Call-ID/from-tag/to-tag satisfy the requirements? Keith: I'm afraid of mixing up from and to tags with this, what were your original requirements for a unique identifier for the session? Also, not all B2B user agents, in the full sense of the term, will be able to satisfy this, e.g. conference bridges. Darryl Malus: Has to be so completely anonymous that no one will care about re-writing it. ?: We had some examples of where this wouldn't apply, e.g. conferences or transfers, to this I would add disaggregated media like SPLICES; we can't boil the ocean, but I'm on the fence about whether it's worth chartering just this small part. James Polk: Question about Robert's observation Hadriel: Clarify, if you don't have B2BUA, is Dialog ID to Session ID always a one-to-one mapping, even with refer, conference, etc. James Polk: in this case, yes. If refer changes to/from/call-id Robert: In particular, I'm in a call with you, called A, you transfer my call to Cullen, that's now B. Cullen: if twenty people are called into a conference bridge, each of those is a different ID. Hadriel: In forking cases, each fork will have a different session ID. And out-of-dialog ID doesn't have the full set. Keith: I'm concerned that Hadriel's already defining requirements around the solution what you need is a unique identifier; do you want your forked endpoints to have a different unique identifier or not? Paul: If a call Cullen, and he's using his corporate phone system, and he puts me on hold with music-on-hold and then takes me off hold, do I have the same session-ID with the music-on-hold system as with Cullen? Salvatore: it depends how your system is designed Roni: it confuses me why people are asking if it's unique here, or unique there, when it depends what your requirements are, we need to define it Hadriel: we don't mean to talk about the solution, but we're clarifying the charter sentence about from-tag, to-tag, call-ID. Sohel: Useful to have a main ID and sub-IDs, like forked calls. Salvatore: if you have forking, then one path survives, that's the one that gets the session ID. David Schwartz: Aren't you really looking for an identifier between administrative domains? Do I care who the end user is? I don't know who's behind someone else's PBX. I just need to correlate things local to me. Maybe part of the problem is just fixing the Call-ID, it has silly things like IPs and MAC addresses. Darryl: I think we talked about Call-ID, and why don't we use that, in the previous meeting; I'm in favor of this, I've been doing performance metrics, it's very hard to correlate performance metrics without this. Cullen: we've had quite a bit of discussion about what the scope of this is, and we know it doesn't solve all the uses cases, and also discussion about whether it will get through SBCs. Are there any other issues people want to bring up before we bring this charter to the ADs? Jon Peterson: do we want, separately, to clean up Call-ID? Cullen: my reading is that fixing the Call-ID, and there was some way SBCs could know that a given Call-ID was indeed a fixed one, would be in scope of this charter, but it's not clear that people want to go this way. Keith: The Call-ID has two functions, to identify the session and to identify the end user, which are mixed together, and if you fix one of these you break the other functionality. Hadriel: SBCs are only half the problem, other SBCs must change the Call-ID for architectural reasons. Jon Peterson: A lot of B2BUAs that routinely destroy dialog-IDs today would also end up destroying Session-ID values, it's not clear to me how they would survive. Robert: A scenario where Dialog-IDs are destroyed: a B2BUA is putting me in a call with different things, and move me without my knowing, how does that work with Session-ID when I'm moved? Hadriel: In some scenarios, it may be that it's impossible for the full session ID to follow me through the whole "call". But adding a new header means you won't break SIP, whereas changing Call-ID semantics could; you'll just have some cases where the new features Session-ID gives you could break. Keith: Does it remain static for the duration of the session, even as the characteristics of the session change? Darryl: If one endpoint stays the same but the session-ID changes, it makes it very hard to correlate things. What we need to understand is which corner cases are in or out of the scope of the charter? In these scenarios, you can count on session-ID, in these others, just give up. Gonzalo: the way we are writing this charter is quite strange. Usually we start with use cases, in this case we're starting with a solution and seeing which use cases work with it. Let's make sure we're doing something that will be useful and meets the real use cases we have. Cullen: The charter we have on the table wants to identify use cases that work, within the limitations of the scope we've discussed. We'll take a hum on whether people think this charter is ready and useful, or not. Mary: We've got this charter as it is, this charter updated to more clearly describe restrictions and limitations, and then don't do this at all. Darryl: Question on the charter, I don't know if I would hum if I knew what all these restrictions were. Cullen: The charter we have today says "same aim as call-id/from/to", we know from discussion today the limitations of that. The charter on the table is limited to that case. We might clear up the description of that, but we're taking a hum on something that's substantially the same as what we have. Andrew Allen: let's solve this problem, if we want to solve more problems later then we can recharter or have a new working groups. Hadriel: I would object to listing in the charter the corner cases it won't work in, it depends on what the solution is, it might solve more corner cases than we currently have. Darryl: I want something more than this, but it looks like I'm not going to get it, so I'll solve half my problem rather than none. Hum: strong consensus in favor, with a few scattered hums against. Presentation Vijay Gurbani: SIP Load Balancing Distribute SIP requests to a collection of servers, avoiding oscillation. Many people do this currently, but with no agreed-on mechanism. Current solutions, with their limitationsÉ Considerations for a solution... Split signaling load balancing and media load balancing? Current charter has separate deliverables for this. Do we want to do this work in a new WG, or an existing WG? Sohel Kahn: is the load balancer stateless? It makes the load-balancing decision and then gets out of the way. Vijay: we could do either Cullen: I've built solutions of every one of the types you mention in your "current solutions", and you can always statistically scale load, you don't have to assume all the servers have the same capacity. Vijay: but there's no feedback Cullen: no automated feedback, but you have operator adjustment. The only time this doesn't work is if one server is overloaded, so I don't see how it can be separated from the overload case. None of these existing solutions need any standardization, so I'm not getting what we need to do here that isn't already handled by the overload group. Vijay: you put load on the upstream server when you hit overload. Cullen: but every load balancer needs to deal with this ?, AT&T: we're interested in this. Dale: The real goal of load balancing is that you have a collection of downstream server, the goal is that the aggregate system goes into overload only when the individual systems do. As far as you do interop, the question is if the load balancer is made by a different manufacturer than the downstream servers, how do they communicate feedback. Cullen: The proposal here reminds me of a recent xkcd cartoon. Dale: yes, but a sufficiently good solution will outcompete others. Robert: What actually needs standardization here? I see opportunity for research, and documentation of algorithms, but I'm not seeing an IETF activity that's building a standard. Why aren't you talking to Lars instead of us? Vijay: Are we happy today with how things are? If we get a load balancer from one vendor, and a downstream server from others, do things work without excessive tweaking or configuration? If people are happy with how things are, we can continue as a research item. Sohel: It would be helpful to us to have a document we can point network engineers at, e.g. BCP, to describe what they should do, even if it's not new standards work. Vijay: do people think we need separate work for signaling and media servers? Christer: by "media", do you mean something that affects SDP, or something on the media plane? Vijay: consider a gateway, it might have lots of capacity for signaling. Adam: I agree with Cullen, it would be folly not to follow Overload, so just track whatever decisions are made there. Sohel: In some cases I do need to balance both, they might be the same solution, but we need both. Mary: there were a few suggestions here, we could just use overload, we need new workÉhave you talked to the OPS guys? Vijay: Not yet, I thought they were more IP-level ops. Robert: I'm not going to let the SIP Overload work take this on right now; maybe later, after they've finished their current work. Mary: who is interested in this general topic, do we need to look at this? Hum for people interested, none for "we don't need to look at this". Mary: I don't think we yet have enough consensus about what we want to do. Robert: I think a lot of pressure could be solved by publishing a document describing techniques, whether in the IETF or not. Work on new algorithms should go to IRTF. Doing this work should let us know whether we need new standards work. Presentation: Penn Pfautz: Global Service Provider ID Want to identify provider who is ultimately responsible for providing service to an E.164 number. Demand from a lot of domains, want something that can be given to non-traditional entities. (Thus, unlikely to get it from ITU.) Jonathan Lennox: What about ITAD? Penn: That's one thing we've thought out about. It's not natively a fixed-length string. Also thought about SNMP Private Enterprise Numbers. Sohel Kahn: I support the draft, as a provider I think we need something like this; it's not just the provider identifier, we need something at the end so the same provider can have multiple networks to route traffic to. Hadriel: I support the concept of this, I think there's a confusion of a namespace with the encoding of the namespace, we can encode things however we want. The question is whether we need a new namespace, or can reuse an existing one. The concern with ITAD is that there already are a lot of unrelated uses. But if it's open, then it's open, anyone can get one, and I will. Penn: If you say "it's only for service providers", then the question is who's a provider. Dale Worley: A few minutes ago I would have given the same comments Hadriel did with respect to private enterprise numbers. I think the problem is there are requirements that aren't stated. E.g. a prefix/suffix portion so entities can subdivide their number space. Penn: No, people wanted to do prefixing in a routing engine. Cullen: ITAD Registry *does* allow a single person to get multiple registries. Brian Rosen: I don't think you've sufficiently motivated why it has to be numeric, or why fixed-length, for interchange/standards purposes. ?: I was also wondering why the 8 digits, 8 digits means a lot of registrations, is this going to be a huge registry for IANA? Penn: It's not going to be huge. ?: 8 digits was a guess, leaving space for the future. Amrit: I support the draft, what we have here is a discussion of the class of registry we need, I support a fresh registry. From a Dispatch point of view we're not discussing a new protocol, we don't need a new WG or anything. Next step should be a new mailing list. David Schwartz: I support the draft, but I think there's a lot that's unclear, e.g. you don't want to encode network topology into the identifier. I also get concerned with the combination of "fixed-length" and "open registration", which would let someone register your whole namespace. Dale Worley: I support the concept of what you're doing. I believe the concept of limiting it to 8 digits is not sufficient; it's not even sufficient to limit it to one per human. We've also already made the mistake of having two registries that do essentially the same thing. I think you know why you want another registry but I haven't heard it. Penn: Personally, I want *a* registry, but there are parties who want a new one. Jon Peterson: You said this was progressing independently in SG2? Richard Shockey: It was discussed in SG2, it is no longer an issue there. Penn: I don't know if it has formally been staked through the heart, but I would be willing to bet all the cash in my pocket that it won't go anywhere. Jon: We have a responsibility for a liason if we're formally doing work that duplicates work elsewhere. Richard: it won't be an issue. Cullen: I don't see this becoming a WG, just some AD-sponsored drafts. Cullen: Hum for creating a URN for this: strong hum for, none against. Richard: My proposal is to create a new mailing list. Cullen: All the people who would join the list wrote the draft, all the people who spoke against it wouldn't join. We can create a list if it threatens to overwhelm Dispatch. Gonzalo: Usually Dispatch is for charter discussion, but Rai could be used for the general discussion. Hadriel: to avoid turning Dispatch into Sipping, can we dispatch this to Drinks? Gonzalo: Drinks has a lot of energy issues, that's why I'd rather use general RAI. Hadriel: I didn't hear that suggestion before, that's fine. New presentation: Revision of BFCP, Charles Eckel Differences from previous draft, now intended for informational Use case: SIP videoconferencing, one existing endpoint may become the conference server; conference server may be behind a NAT. Existing NAT traversal toolkits for UDP doesn't work for TCP. This draft defines BFCP for UDP, to leverage existing toolkit for RTP, changes existing BFCP as little as possible. Description: new bit that indicates request/response of transaction. Adam Roach: Do you anticipate gatewaying between TCP and UDP for this? How would a gateway insert this information if it's not present in the TCP stream? Robert: what are we doing? Cullen: The idea was to see if people were okay with doing it over UDP, that's two slides forward. Charles: finish of presentation Cullen: The issue is whether people are okay doing this over UDP, after we resolve this we can figure out what to do with that. Gonzalo: A similar issue happened with Reload, we rolled our own transport, that was fine. This seems like a good idea. Bringing it to XCon is probably a bad idea, that group is wrapping up. I think we should be working on this. Adam Roach: I think if we're going to work on this, it should go into a WG. If we're going to have two versions of this protocol, we have to think about how they should co-exist, that's not the sort of thing you can do as individual AD-sponsored. Allyn: It's not clear to me whether this is informational about what the industry is already doing, or whether this is new IETF work. Gonzalo: I would prefer new standards work, rather than documenting what someone's doing. Keith: My concern is that you can convert a protocol that assumes reliable transport to one that has its own reliable transport just by adding responses. The responses have to be reliable in their own right. Brian Rosen: If this document is documenting existing practice, then just document existing practice. If it's for future implementations, then it deserves every bit of our usual process. Allyn: I don't think people who are currently doing things necessarily want to have further development. Cullen: Multiple documents, Cisco's implementation, Polycom's implementation, or one document they can all implement to and be interoperable? Allyn: they're already interoperable Charles: This was in the IETF standards-track before, this was written as a BFCPbis, but there was a lot of pushback on that and people would rather get TCP working natively, so I went to Informational because the IETF would rather get TCP flows working properly, and we need to document what we're doing in the meantime. Magnus: This is a suggestion for a new standards-track protocol as far as I can tell, even if it's called Informational. Charles: The vendors in the IMTC SIP Parity work are implementing this. ?: We're not just documenting existing practice, we're describing what what we want people to implement. Roni: It depends on what are the use cases for this UDP-based approach. If it's just for this use case, there's no problem having it as Informational; if there are other use cases, we probably need it as standards track. Cullen: hum on whether there should be IETF work on BFCP-over-UDP, as opposed to individual submission Hum: Strong consensus for, one (or a few) hums against. Hum: standards-track, informational, or don't care Equal among the people who are, most people don't care. Will defer to AD. Close of meeting. Detailed Notes: (Christer Holmberg): ------------------------------------ Topic: Session-id Presenter: Salvatore Loreto Focus: Use-cases and proposed charter Draft: draft-jones-ipmc-session-id-reqts-00 The presenter suggested that the work should only cover a limited set of use-cases. It was commented that the draft discusses many more use-cases, and that people are interested in a solution that also solves use-cases not listed in the suggested charter. It was indicated that, in order to solve more use-cases, a re-charter would be needed, but that everytime people have tried to expand the proposed charter something has come up that others are not happy with. It was indicated that, instead of talking about which use-cases are NOT covered, we should focus on the use-cases that we do want to solve. It was indicated that there would need to be a requirement on SBC customers not to modify the session-id information. However, it is not possible to make such requirement, as it is not technical, and since there might be different reasons why customers want to remove/modify specific information. It was indicated that there might be different understandings on what the identified session is, and it needs to be clear in order for everyone to have a common understanding. It was asked whether the problem could be solved by making sure that user identity is not revealed in the Call-Id header. However, there might be other reasons why B2BUAs need to modify the Call-Id. In addition to the charter discussions, there were discussions whether forking is covered, whether end-users need the information, and whether the session-id can change during the call, e.g. due to different applications, but where the call is still considered to be the same. It was clarified that, if it could be guaranteed that it would remain unchanged, the Call-Id would solve the use-cases in the currently proposed charter. HUM: Question: People who are in favor in moving forward with the propsed charter? vs People who are in oppose in moving forward with the propsed charter? Result: There was strong consensus in favor of moving the work forward. ------------- Topic: Load balancing Presenter: Vijay Gurbani Focus: Proposed charter Draft: None specific for the meeting. It was commented that the difference between overload control is not clear. It was indicated that, with load balancing, you will not have to put effort associated with overload control, as the idea is to avoid overload scenarios to take place. It was commented that there currently are multiple different solutions available, without any guarantee of interoperability, but that a standardized solution hopefully would make that problem go away. It was questioned what, if any, IETF standardization work is needed, or whether this would be better as a reasearch topic? It was indicated that there are solutions that be used to provide feedback from server, which receiving entities might use to perform load balancing, and that it would be good to have a BCP or use-case document. It was indicated that there has been no discussions with the APPS people regarding this topic. There was an indication that people are interested in the topic as such, but that it is unclear where and what work should be done. People were encouraged to continue the discussions per e-mail, and it was indicated that the focus should be on what needs to be done from an engineering perspective. ------------- Topic: Binary Floor Control Protocol (BFCP) Presenter: Charles Eckel Focus: Proposed charter Draft: draft-sandbakken-dispatch-bfcp-udp It was indicated that, if it is possible to do BFCP both with UDP and TCP, there might be a need to specify gateway procedures, as we don't want to mandate support of both transport options. It was discussed where the work would be done, as the XCON WG is closing up. Most likely a mini WG would be created. Also indicated that it needs to be done in a WG, rather than as an AD sponsored wrok, as one would have to deal with how different versions of the protocol wold interoperate. Indicated that there seems to be an assumption that a protocol that relies on a reliable transport can be moved to an unreliable transport just by adding responses. There was some confusion of what the purpose, and intended outcome of the work is. If the purpose is to simply describe existing implementations, the outcome should beinformational rather than a standards track. It was claried that the proposal is for a new standards track protocol. HUM: Question: Are people in favor in IETF publishing an RFC how to do BFCF over UDP? Result: Strong concensus for doing BFCP over UDP. HUM: Question: Do people whink it should be standards/informational/do not care? Result: Equal between people who care, and more strong among people who do not care.