SIMPLE Interim Meeting
Morning Session Minutes
Monday 24th May 2004
- MSRP – Ben Campbell (draft-ietf-simple-message-sessions-06)
- New in 06 (slides)
- Changed to/from to-path and from-path.
- Semantics different than traditional to/from confusion insued.
- Framing: Use boundary instead of length field.
- SDP: Transport and TLS indicated in URL rather than M-Line
- Inviter always opens the connections.
- Updated DSN section.
- Relationship to relay draft
- Core specification talks about route path handling.
- Makes minimum necessary assumptions about relay behavior to allow relays.
- Does not talk about how relays work or how endpoints work.
- Path handling in SDP
- Each client puts a URL into a path attribute.
- Can put more than one URL in the path attribute.
- The path given by peer indications the ";Peer to peer path";.
- Path handling in MSRP requests
- To-path holds a list of URLS.
- Path to destination
- First URL is first hop
- Last entry is destination.
- From-URL also takes a list.
- Where it's been?
- Initial request has one entry pointing to client.
- When request arrives at destination, it will contain URLs for all hops.
- Request Framing
- Length field goes away.
- Add boundary header.
- Random string (different for each message)
- Matching closing field
- 7 hyphens
- Boundary string
- Continuation char ($ if content complete, + if more to come).
- Request Framing (part 2)
- There's a lot of confusion of MSRP boundaries being independent of the MIME boundaries.
- Full MIME body between headers and closing. May have its own MIME boundaries.
- Presence of MIME boundaries does not change use of MSRP boundary.
- Boundary must not collide with payload.
- Cannot use same boundary
string for MSRP boundaries as MIME boundaries
- (Cullen/Campbell: Needed to take this approach so that we can
interrupt a stream without killing the connection.)
- (Henning: Worried that this is going to be so close to MIME that it could be confusing to implementers as to what's a MIME boundary, and what's an MSRP boundary. Might use MIME processing code to handle MSRP boundaries accidentally.)
- (Rohan Mahy: We can change it if necessary.)
- (Cullen: I agree w/ Henning, we can make it the same if there's confusion.)
- Other SDP changes
- Transport and TLS determined by URL scheme, rather than M-line.
- Msrp: - TCP
- Msrps – TLS over TCP
- Smsrp – SCTP
- Smsrps –TLS over STCP
- SCTP related schema are ";reserved"; for whenever we specify the SCTP binding.
- (Ted Hardy [AD] – Worried that you're reserving so many schemes.)
- (Ben: Adam/Rohan/Cullen and myself had a discussion on this. Not beholden to this approach if there's something better out there.)
- (Ted: May want to get some URI folk brought into the discussion. Not sure that you want to specify
this in the scheme.)
- (Ben: We have not gone through and said that you must support SCTP)
- (Adam Roach: We wanted to show how different transports would appear in the URI)
- (Rohan: There are a number of permutations that you can have.)
- (Audience 1: Why not use SIP/SIPS approach?)
- (Cullen: That's what I wanted.)
- (Adam: MSRP does not lend itself to the same SIP/SIPS approach because of the way that MSRP works. It would be odd.)
- -->Ben quickly crafts some examples in the slides:
- msrp://host/asf:port:transport=tcp;protection=yes
- msrps://host/adsf3:port;transport=tcp
- msrps://host/tcp/asfed:port
- (Ted: Not a lot of use cases out there that I can think of where every session that is used uses hop-by-hop TLS. Doesn't work that way for email. I'm not trying to say that this doesn't make sense, but I think it would make more sense to use a common URI scheme. I don't think that there is going to be a collision problem in the future if the various schemes were not registered all at once.)
- (Jon Peterson: The only reason we did SIPS at all is to allow an immediate failure if there is no host listed in DNS that did not support TLS, that there would be an immediate failure.)
- (Adam: How do I specify on that link that I want TLS or failure for MSRP?)
- (Jon: Don't know.)
- (Rohan Mahy: I think we've found a requirement that we should be able to specify whether a missing transport is a failure, or if any type of transport is OK. We had said that there was no negotiation possible, that you could look at the list and figure out immediately what you were going to use.)
- (Ben Campbell: In MSRP there is no NAPTR lookup.)
- (Jon: Perhaps we can defer this discussion later to when we've determined if we need SCTP, etc.)
- (Adam: We need to know if it's going to be an opaque token, or the scheme now. We can't mix and match later. We don't need to register the tokens, but we need to know the syntax.)
- (Jon: I'm saying two things. If you use TLS, it has to specified in the transport address, and two, whether or not we need TLS.)
- (Ted Hardy: What would happen if we said you always have to use TLS.)
- (Rohan Mahy: The relay-relay communication must use TLS. Peer-to-peer connections aren't required to use TLS because certificate management is too difficult.)
- (Ted Hardy: TLS lets you get beyond that.)
- (Jon Peterson: I think Ted's question is interesting.)
- (Rohan Mahy: This is worse, because we waste time on the TCP setup to know if we need to use TLS.)
- (Jon Peterson: What do you do for authentication when TCP only is used?)
- (Cullen: We use a URI that is secret and hard to figure out. It's not great, but that's what's there.)
- (Jon Peterson: I don't see that TLS makes this any worse. If all you're doing is waiting for the SYN packet and dropping the connection because you don't like the looks of it, TLS is no worse.)
- (Rohan Mahy: If I have no certificate that is meaningful to provide you, and you open a TLS connection, I have to have a completely different code-path to handle this connection.)
- (Cullen: The smallest implementation for TLS is 120K. Are there any wireless device vendors here that don't want to carry 120K around with them?)
- (Keith Drage: 3GPP does not specify that you must have relays at all.)
- (Ben Campbell: I think that we've come to the conclusion that we have more thinking to do.)
- (Jon Peterson: I don't like that conclusion. I think we should resolve it now.)
- (Hisham Khartabil: If we think this should be in the scheme, then this is what we have. If you think it should be a parameter, then we need to know what that is now.)
- (Ben Campbell: I think we've said that we can drop smsrp and smsrps from the URI combinations. Also, killing off msrps://host/tcp/asfed, where the transport is in the URI path.)
- (Rohan Mahy: It was pointed out that we don't have to select all of the schemes immediately, we should go to the URI list and let folks know what the options are.)
- (Cullen: By not saying anything, we're choosing the scheme approach.)
- (Jon Peterson: We're saying that extensions to MSRP are going to have to specify additional parameters anyhow, so inclusion of parameters means additional work ala TLS, etc.)
- (Adam Roach: That doesn't work because a relay that's not familiar with the extension won't interpret the parameter correctly.)
- (Rohan Mahy: I don't need to know what parameters are if I just stick them into the list.)
- (Jon Peterson: Can we say that this is version 1 of MSRP, and that we version out the problem. You can put the version in the scheme.)
- (Ben Campbell: That's pretty much what we're doing.)
- (Jon Peterson: I want to close this out.)
- (Rohan Mahy: [Question to Room] does anyone have a problem with always having to have transport=tcp in the URI.)
- (Jon Peterson: Doesn't make sense to have a protocol with one transport have a parameter specifying the transport as a mandatory element.)
- (Hisham Khartabil [WGC]: No transport parameter means TCP.)
- (Ben: I wanted to specify TLS as a transport.)
- (Ted Hardy: If you want to see this as an orthogonal parameter, then TCP remains the default, and you negotiate towards TLS. I still would like to have the URI folks take a look at this for a little bit to ensure that we haven't made a mistake.)
- (Ben Campbell: For the sake of closure, would it make sense to have this room pick a candidate to send it to the URI folks.)
- (Aki Niemi: Is the behavior that we intend to be failure if I don't understand what you're asking for, or do I fail-back to TCP?)
- (Ben Campbell: There's a question as to whether or not we can fail-down to TCP.)
- (Robert Sparks[WGC]: We can always approach this as an offer-answer model to negotiate down to TCP.)
- (Ronnie: The behavior needs to be clearly specified.)
- (Robert Sparks [WGC]: Need to move on.)
- (Ben Campbell: I was going to say that we go with msrps://host/asdf3;transport=tcp. TLS goes into the scheme, there's a transport parameter.)
- (Robert Sparks[WGC]: Need to specify the equality rules for what happens if a transport is missing.)
- (Ben Campbell: If I put MSRP in the SDP I must put the transport in there.)
- (Adam Roach: Can we simply make it ";;tcp";?)
- (Ben Campbell: Sure.)
- Connection Handling
- Default to TCP connection opened by client that sends the INVITE.
- Active client MUST send an immediate MSRP request, so the peer can tell who opened the connection.
- May be SEND if there is a message to send right away.
- Otherwise use VISIT.
- Inviter must wait for answer before connecting.
- Delivery Status Nofitication
- Only specifies enough to let an endpoint without relay support talk to peers that use relays.
- RFC1984 format
- DSN requested on per request basis.
- Receipt-Request header field.
- Negative – only report on failures (relays only)
- None – never report
- All – report failures and delivery success.
- (Might need a fourth one, positive, opposite of negative)
- Default is ";negative";
- Sent using REPORT method
- Never REPORT on a RECEIPT
- Message Fragmentation
- May break content into ";parcels"; using message/byte ranges
- Only message/byte ranges content can be interrupted and resumed.
- SHOULD fragment anything over 2K.
- Final parcel uses ";$"; in the continuation flag field. Non-final parcels use ";+";
- (Adam: The should fragment is a little bit misleading. You should make fragmentable anything over 2K, so relays can chop it up if they want to, but it's not mandatory.)
- (Robert Sparks[WGC]: If I'm in the middle of sending one of these huge streams, and I get a request I need to respond to, I can interrupt what I'm doing to respond rather than running into the head-of-line problem.)
- (Rohan: If I'm an MSRP
client that receives a SEND, that contains a boundary with a ";$"; I know
I'm safe to render. I might buffer on a ";+"; and send a DSN though.)
- (Cullen Jennings: If the total is ";*"; I don't understand what the ";$"; does for me because things may arrive out of order if we go through relays.)
- (Adam: They can go through different paths through A-record round-robining. We need more text around the ";*"; mechanism, but it works.)
- (Ben Campbell: DSNs indicate delivery, not rendering or viewing by the user.)
- (Aki Niemi: What if I want to abort, how do I tell the sender to stop?)
- (Ben Campbell: There's no way for the receiver to tell the sender to abort. I'm running out of memory. I want to stop things without interrupting my connection to the relay.)
- (Cullen/Robert: Download should be a separate session. Can send a re-invite to get a new stream or a BYE.)
- (Audience 1: We really don't say what muting a connection does for MSRP. We should perhaps expand what that means.)
- (Aki Niemi: With relays involved, I see two ways to do the same thing. Can we pick one that works both end-to-end and with relays so that we only have to support one method.)
- (Ben Campbell: Can we defer this? I'd hate to make end-to-end connections support REPORT because I don't want chaining properties.)
- (Jon Peterson: Have we closed with the MIME folks to see if the usage of multi-part byteranges here meshes with their use?)
- (Ted Hardy: This does turn it into a bucket MIME type because you don't know what the real MIME type is going to be. It's always set to multi-part.)
- (Ben Campbell: Do we need to negotiate partial/multi-part MIME in the SDP? I hope not.)
- (Ted Hardy: You might want to specify a parameter that lists what the internal MIME types are in the SDP so you can tell what you're going to get initially rather than later on.)
- (Rohan Mahy: This message fragmentation is one of the things that I worry about the grey-beards of email pondering what we're doing.)
- (Ted Hardy [AD]: I'll send one emails off asking about that.)
- SDP Issues
- How will SIP delayed offers work?
- Can we expect the answerer to propose MSRP rather than voice?
- Should we specify what a client that supports MSRP should do if it gets an INVITE with no offer?
- Do we want this much SIP specificity in this document?
- (Rohan Mahy: I was trying to prevent a race condition where in the SIP usage of this, if a SIP usage received an offer and wanted to answer, especially in the INVITE/200 INVITE/18x (reliable) that my client could not respond to this request because of MSRP work pending. If something occurs where I got an offer and I went to make a new connection, and setup a session of voice, and then update to setup IM, and TCP takes awhile… I may blow out the INVITE transaction timer and black hole myself. Once you receive the offer, you, as the answerer can do what you need to. Can setup the TCP connection and if it fails, re-INVITE.)
- (Ben Campbell: Trying very hard to make MSRP not dependent on SIP. If I send an INVITE with no offer, why do I expect the other guy to ever send MSRP? [brief discussion] The problem of getting an INVITE without an offer is not an issue.)
- (Rohan Mahy: The answerer needs to send immediately.)
- (Ben Campbell: The offerer cannot send an MSRP request until the active party [answerer] send it a request, because if could be someone randomly connecting to the port.)
- (Paul Kyzviat: We need to specify how re-INVITE works.)
- (Audience 1: I agree. If the re-INVITE fails, what happens to the original connection?)
- (Aki Niemi: The text is confusing on this area.)
- (Ben Campbell: I believe there's some errors in the text. I need to revise.)
- (Rohan Mahy: This was heavily cut & pasted from SIMS which was heavily cut & pasted from a memo between Cullen and I.)
- (Adam: Why not simply use offer/answer rules.)
- (Rohan Mahy: If that's the consensus of the group, I'm OK with making sure there's no holes in that.)
- SDP Issues
- Old text on updated offers obsolete with new approach to connection direction.
- Section needs a re-write.
- SDP offer/answer arcane experts please help (contact Ben).
- Connection Direction
- Number of non-relay scenarios reduced
- Offerer must choose whether to use relay prior to making offer. If the answer is not firewalled, the offerer cannot learn of this until too late.
- Thus, a firewalled answerer will always propose a relay, even if the answerer is reachable.
- A firewalled answerer must use a relay, even if the offerer is reachable.
- (Cullen: If the device that is behind a NAT that breaks the network, they must use a relay.)
- (Aki Niemi: Any device behind a firewall always has a path that it must put in its SDP, the offerer has one, and the answerer has another, how does that work?)
- (Ben Campbell: That never happens in the core spec. It needs to go in the relay spec.)
- (Aki Niemi: Issue is not clear.)
- (Ben Campbell: Text needs to be updated to make this clearer.)
- Fragmentation
- How much of the RFC-2616 language concerning message/byte ranges do we need to reproduce here?
- Currently only refers to RFC, and add tect that specifically constrains the use in MSRP. Does not explain message/byte ranges in general.
- (Henning: Is that text sufficiently contained so that someone doesn't have to read all of 2616?)
- (Ben Campbell: yes.)
- (Adam: We've made some modifications, like wildcarding that needs to be explained.)
- SEND vs. VISIT
- VISIT has become less important
- VISIT only serves to identify the active party to the passive party, in the context of a particular session.
- Active party may jump straight to SEND if it has context to send.
- Since the active party initiated communication in the first place, it probably has content.
- Can we remove VISIT entirely?
- Should we require VISIT all the time, and not overload SIP?
- (Rohan Mahy: If you were in fact, able to come up with the URI, then you can send the VISIT. You need TLS to authenticate.)
- (Adam Roach: If you are starting up a session that has multi-media associated with it, we may not setup Ims immediately. The second scenario is conference…)
- (Ben Campbell: I never said it always has to SEND. We could send an empty SEND, or we could simply not overload the method. Offerer would have to VISIT and then SEND.)
- (Rohan Mahy: If you have something to send, SEND, otherwise VISIT, which is what the text says.)
- (Ben Campbell: Propose leaving VISIT in the draft. If SEND with no body will work, I'll rip it out, but it'll have to be decided soon.)
- DSN Issues
- Do we need them at all?
- What about DSN reports after session is over?
- Should we default to no DSN for peer-to-peer session?
- DSN is redundant with transaction responses for p2p?
- DSN section needs to be updated to use new handling of to-path/from-path.
- (Ben Campbell: Intent was that if next hop failed, the reason code was included.)
- (Rohan Mahy: Want to base this on message ID and not transaction ID.)
- (Ben Campbell: Old draft. Has been/will be fixed to message ID.)
- GENERAL CONVERSATION
- Ben Campbell: If we have a response that says ";stop sending me crap without TLS"; do we need TLS negotiation?
- Adam: Sounds like it's mandatory for TLS to be used between relays.
- Rohan Mahy: I'd be perfectly happy with if the URI contains a port/transport/protection level explicitly, the server knows if the port offered supports what was asked for.
- Cullen Jennings: I'd rather avoid the peek 3 bytes ahead issue around TLS.
- Ben Campbell: I was going to send an explicit start TLS. But if I know that I'm always going to do TLS why do I need a response code that says do TLS? Does anyone have any heartache over removing negotiation between relays around TLS? [Room is generally quiet, Henning agrees
[END OF BEN'S PRESENTATION.]
- Rohan's MSRP Relay Draft Discussion
- Ben Campbell: We do
request/response, request/respone, etc. as opposed to request, request, request… response, response, response.
- Rohan Mahy: Yes. If a message goes from a fat pipe to a slow pipe, I know how long to wait for a response at the sender from a SEND. It also allows chunking at the relays.
- Orit Levin: I think MSRP is not going to be useful without the relay draft. This piece is very important. We should dicuss this draft from a conceptual point of view. For instance, does it make sense for the user to know about all the relays in the path. It may not be practical. I fear that we may be
wasting time by discussing each method, when we have not gone over the basics.
- Rohan Mahy: I hear that you have an issue with relay discovery beyond the first relay. I would like to discuss that. I'd like to discuss the flow though as it has more profound impacts on the protocol.
- Robert Sparks[WGC]: We're going over the various methods to see if we have something missing in the architecture or something we don't need.
- Rohan Mahy: We can discuss this.
- Hisham Khartabil[WGC]: Chunking will only work if request/responses are end to end.
- [Moving on to relay discovery]
- Rohan Mahy: I can use DNS-SRV to discover a relay. Requires more work by the client.
- Orit Levin: From my perspective, I don't want my client to know about subsequent relays and that it may not be able to authenticate with those relays.
- Rohan Mahy: It can be hidden.
- Orit Levin: When relays know about each other, and authenticate with each other explicitly, I don't think it's important that the client talk to the relays directly.
- Rohan Mahy: Draft needs work. Will be updated.
[END OF Rohan's MSRP Relay Discussion]
Orit Levin's MSRP End-to-End Discussion:
- Two Distinct Mechanisms
- Application Later: End-to-end
- Network Layer: hop-by-hop
- For improved feedback (to application layer) in case of network failure.
- Require configuration of the first relay (only)
- The very first deployment will use RELAYs
- Don't build interim solutions for one hop only.
- End-to-end abstraction MUST be provided even over a single hop.
- Applications need to be exposed to the end-to-end view ONLY.
- (Orit Levin: Endpoints can't know the network topology. First implementation of MSRP will include relays, I don't see the overall model in our discussion.)
- (Ben Campbell: The main reason we're breaking up relays from the core draft. It's an IETF process decision so both drafts can move forward.)
- Hop-by-hop Mechanism
- Added Value
- Automatic negative feedback in case of TCP link failure without additional application logic: requires state information (at least MSRP connection) in relays.
- Ability to specify (with high probability) messages that have been affected by the failure – requires per message state + 200 OK.
- Improving timing for ";stalled"; TCP connections – requires ";per something"; state + ";200 OK"; + timer.
- Issues
- Specific message information can be misleading.
- OVERHEAD for BIG deployments (>25%, easily 50%)
- Lack of throttling manageability for MUXing and CONFERENCING.
- (Cullen: The error case you propose in your draft, I'm not sure that if the network disappears at the right point in time you can't get a response back. It's unsolvable.)
- (Ben Campbell: Looking at the models you describe in the simulations you ran a modified SIP state machine to get your numbers. SIP is a far more complex state machine than MSRP. Because of that, because of the timers and things that MSRP doesn't have to do, the overhead is proportionately less. I think you'll come up with a significantly lower number. However, it still becomes an efficiency vs. generality argument.)
- (Orit Levin: I think the number will go up, rather than down. For MSRP the amount of work being done goes way down and the overhead becomes larger.)
- (Ben Campbell: Based on that, a test based on SIP doesn't tell us anything. It could be higher or it could be lower.)
- (Cullen Jennings: Perhaps if DSN is set to NONE, we don't set any timers, and don't send back any responses.)
- (Orit Levin: I would like for us to deal with what we would like to achieve, and then work into the messaging, rather than the other way around.)
- (Robert Sparks[WGC]: If we don't send responses, the DSN only tells us something failed, and not when. Every session that happened to be on that TCP session [ever] is going to get a DSN back that something failed.)
- (Adam Roach: One of the requirements of a relay is to be able to operate statelessly at the session level.)
- (Cullen Jennings: I want a reliable model, and you want an unreliable model.)
- (Jon Peterson[AD]: I understand that what you want to do is revert this entire discussion to requirements. We've done that before here at SIMPLE.)
- (Orit Levin: I want to show what the implications are. They need to know what will happen.)
- (Jon Peterson: You want to start over with a new protocol, with different assumptions.)
- (Orit Levin: We can go through with Cullen's suggestion, and we can go through the rest of the slides.)
- (Jon Peterson[AD]: We're required by the CPIM RFCs to be reliable and provide positive acknowledgements.)
- (Jonathan Rosenberg: If we can reach a compromise, let's do so.)
- (Adam Roach: We're building TCP over TCP.)
- (Robert Sparks[WGC] – Tried to gain consensus, but still muddied.)
[END OF DISCUSSION]
Chairs:
Robert Sparks rsparks@dynamicsoft.com
Hisham Khartabil hisham.khartabil@nokia.com
Rohan Mahy rohan@cisco.com
Adam Roach adam@dynamicsoft.com
Ben Campbell bcampbell@dynamicsoft.com
Henning Schulzrinne hgs@cs.columbia.edu
Keith Drage drage@lucent.com
Jon Peterson jon.peterson@neustar.com
Kurt Bertone kurt@convergence.com
Peter Mataga mataga@avaya.com
Jonathan Rosenberg jdrosen@dynamicsoft.com
Paul Kyzivat pkyzivat@cisco.com
Gonzalo Camarillo gonzalo.camarillo@ericsson.com
Christer Holmberg christer.holmberg@ericsson.com
George Foti george.foti@ericsson.com
Thomas Froment thomas.froment@alcatel.fr
Shida Schubert shida@ntt-at.com
Cyrus Shaoul cyrus@ntt-at.com
Dorothy Gellert dorothy.gellert@nokia.com
Markus Isomaki markus.isomaki@nokia.com
Aki Niemi aki.niemi@nokia.com
Anwar Siddique anwars@avaya.com
Ashir Ahmed a.ahmed@ntt.com
Mahfuzur Rahman mahfuz@research.panasonic.com
Bob Penfield bpenfield@acmepacket.com
Yaron Reinharts yaronr@il.ibm.com
Cullen Jennings fluffy@cisco.com
Ted Hardie hardie@qualcomm.com
John Elwell john.elwell@siemens.com
Orit Levin oritl@microsoft.com
John Lawser lawser@att.com
Martin Dolly mdolly@att.com
Alan Johnston alan.johnston@mci.com
Henry Sinnreich henry.sinnreich@mci.com
Miguel Garcia miguel.an.garcia@nokia.com
Mihko Lonnfors mikko.lonnfors@nokia.com
Radhika Roy rrroy@att.com
Bill Marshall wtm@research.att.com
Chris Boulton cboulton@ubiquity.com
Christian Schmidt christian.schmidt@siemens.com
Kumiko Ono ono.kumiko@lab.ntt.co.jp
Dan Petrie dpetrie@pingtel.com
Roni Even roni.even@polycom.co.il
Francois Audet audet@nortelnetworks.com
Mary Barnes mary.barnes@nortelnetworks.com
Brain Stucker bstucker@nortelnetworks.com
Dale Moberg dmoberg@nortelnetworks.com
Scott Bradner sob@harvard.edu
Kwok Ho Chan khchan@nortelnetworks.com
Asher Shiratzky ashers@radvision.com
Dean Willis dwillis@dynamicsoft.com
David Oran oran@cisco.com
Tom Phelan tphelan@sonusnet.com
Mark Zeren mzeren@artisoft.com
John Buford buford@research.panasonic.com
|
Morning