Binary Floor Control Protocol Bis (bfcpbis) ======================================================= Chairs: Keith Drage Charles Eckel [Mary Barnes is filling in for Keith at the meeting] Agenda IETF 82, Taipei 0900-1130 WEDNESDAY, November 16, 2011. Room: 3F Banquet ----------------------------------------------------------------- 09:00 BFCPBIS Status Update (Chairs, 20) Note well. Note takers assigned: Paul Kyzivat Jean Mahoney Jabber scribe assigned: Hadriel Kaplan Jabber logs: http://www.ietf.org/jabber/logs/bfcpbis/2011-11-16.html Meetecho Recording: http://www.meetecho.com/ietf82/recordings Charter presented. No questions or issues raised. ------------------------------------------------------------------- 09:20 Revision of the Binary Floor Control Protocol (Charles, 30) for use over an unreliable transport draft-sandbakken-dispatch-bfcp-udp-03 http://tools.ietf.org/html/draft-sandbakken-dispatch-bfcp-udp-03 Previous version of draft (-02) presented at IETF 81. Updated. = Motivation recap = Establishing TCP connections problematic in some environments, thus define UDP as transport for BFCP. = Reviewed approach = minor changes to transaction model Goodbye/Goodbye Ack New error codes DTLS MUST be supported ICE/STUN if applicable/needed = Open Items = From previous IETFs and/or e-mail list I. DTLS Connection Establishment 3 options: 1 - leave draft as-is 2 - bfcp server could act as DTLS server 3 - 5763 recommendation for establishing DTLS - Charles thinks this 3 is best - doesn't overload OA exchange - helps with B2BUA offerless INVITE Magnus - clarification of issues with option 1. Charles provided additional details on option 3. Advertise active passive. Let the other side chose. Recommendation to be active unless otherwise. Hadriel - no choice but third choice, only viable option Mary, to the group - any concerns? No objections DECISION ==> Charles - draft will be updated for option 3 II. Primitive Specific ACKs vs. Generic ACK == Options: 1 - (Preferred) always send request-spec ack 2 - send request spec ACK only if flag indicates message is initiating a new trxn. Minimizes number of messages over wire, but adds complexity. 3 - generic ack. More easily extensible. Existing implementation back compatibility issue. Mary - Concerns? Roni - Back to primitives slide, what's the change from Prague? What's the [] mean on the new primitives? Charles - [] is used to illustrate that the corresponding explicitly ACK primitive is needed in some cases, but not in others. For example, FloorRequest is followed by FloorRequestStatus. No explicit ACK is needed. Additional FloorRequestStatus primitives may be sent, and for those, the explicit FloorRequestStatusAck is required. The description of the relationship of primitives to each other changed, but no new primitives added, none removed. The open issue of whether an explicit ACK was needed for UserQuery/UserStatus was closed. No new primitive needed because, unlike the FloorRequestStatus, UserStatus is sent in respond to UserQuery only. Adam - back to 3 options. Why not 3? Do we not want to change existing implementations or minimize? Charles - goal is to minimize changes unless there is some real need. Adam - I'm biased towards three. Hadriel - Back to primitives slide, When you update the FloorStatusRequest, does it have the same transaction ID? Charles - has a new one. Hadriel - Concerned about the FloorRequestStatus getting lost. Concerned because of UDP doesn't have ordering. Charles - You don't have to send stale state, the server can send changed state. The client needs to be lenient. Get back to you on list. [Question from Jabber room, but I didn’t get it.] DECISION ==> Mary - this is still on the table. Discuss on the list. III. Large Message Considerations Can be a problem if message exceeds 2^16-1 (for TCP or UDP), or MTU size (UDP only). Options: 1 - (current, preferred) keep it out of scope. Not a problem today 2 - split messages up, use what's defined for reload 3 - add applicability statement 4 - define a SIP event package Hadriel - Things break with fragmentation, doesn't go through NATs. Will developers know about the message sizes when implementing? Charles - the app developers would. The stack developers wouldn't. Lennox - It isn’t sufficient to know what you do – it depends on what the responses will be, and the application can't know that. (e.g. 10k floor IDs in a big conference, connect to a conference much bigger than you ever imagined.) Charles - I would not expect the information of all the participants to be included in the BFCP responses in such cases. Magnus - Need to handle it. Gonzalo - this has been the concern since the beginning. You need to address it. Regarding option 4, there has been some work there, but it didn't move forward. Charles, to the group - reload mechanism seemed promising, but can someone give me more information on how it works. Anyone familiar with it? Brian Rosen - There was not much discussion about it. Don't remember the details mechanism. Mary, summarizing on the options: 1 - no 2 - research 3 - no 4 - look at doc Gonzalo mentioned Gonzalo - RAI ADs to working on it. DECISION ==> options 1 & 3 are off the table, while 2 & 4 will be investigated further. There may an altogether better option in the future. RjS - Summarizing the section in Reload - It intentionally fragments on send and puts information into the headers. Hadriel - it's not generic. Mary - we can model it based on reload. IV. BFCP/STUN demultiplexing STUN is distinguished from the protocol it is used with by first two bits being zero, plus other details of the message. But BFCP also typically has the first two bits set to zero. Options: 1 - (Preferred) leave as defined. It's a non issue 2 - change version number for BFCP Lennox - Issue with message length. Just don't use the magic cookie as the conference ID. 2 is cleaner, can clarify between versions of BFCP. Either is ok. Hadriel - preferred changing the version number – at least because this is another version. Alan - recommends 2, but 1 can work as well. Charles - if using TCP, use version 1. Use 2 for UDP. Roni - suggested to encapsulate the entire thing in RTP headers. Others found this objectionable. DECISION ==> Mary - trend to option 2, Roni can put option 3 on list. Discuss on list. Mary - Assuming that changes are made, adopt draft working group item? hums Opposed? no hums DECISION ==> Consensus in the room to adopt draft as work group item, subject to approval on mailing list Lennox - Draft is a replaces not an update? Mary - yes. 9:48 End =================================