Subject: [Sip] Comments on TOTE

From: <[email-masked]>
Date: Fri, 7 Mar 2008 10:36:12 +0200

Hi,

Here are my views on
http://tools.ietf.org/id/draft-rosenberg-sip-tote-00.txt:

In general there are a lot of things in like about this approach. I
think we definitely need a light-weight, TLS/TCP-based, end-to-end
oriented transport mechanism, with a good NAT traversal story. There are
many use cases for such a mechanism, so instead of developing a specific
one for each of them, it is better to have a common baseline.
Utilization of ICE-TCP and TURN should be a basic requirement here, and
TOTE is indeed using them.

The main issue I see is that MSRP already occupies part of that space.
However, MSRP is not a perfect match. It requires its own specific
relays instead of of being able to use TURN. End-to-end security is
based on S/MIME instead of TLS. It includes a lot of per-message
overhead and also the fragmentation, re-assembly and reporting make it
complicated. Furthermore I'm not convinced a yet how the muxing of
sessions between relays really works: Based on SIMPLE-list, at least two
(independent) implementers have tried to produce a relay like that, but
have concluded that it is not doable. I don't know if other relay
implementations exist. The IMS and OMA folks prefer B2BUAs over relays
for MSRP NAT traversal, and that is the only space I can see some
serious implementation/deployment of MSRP. (This might be because most
people who were originally interested in SIP IM have now switched to
XMPP.) Well, I haven't seen much happening with ICE/TURN-TCP either, but
that could be a chicken-and-egg problem that something like TOTE could
solve. It would be of course helpful if people who came up with MSRP
relay/muxing/chunking requirements would indicate if they still see that
model valid (for customers of MSRP/IM) and if they see a lot of
deployment potential for the protocol.

I also like the model where baseline TOTE would be like SUB/NOT
framework, while the actual usages would be analogous to event packages.
It would be very helpful for developers of new usages if there was a
well-defined and well-working baseline that solved some hard issues like
NAT traversal, e2e security and provided some tools for session
negotiation. I'd be quite liberal about the usages themselves, but of
course the IETF should immediately charter standards-track work on some
of the key ones.

I'm co-author of draft-ietf-mmusic-file-transfer-mech (file transfer O/A
and MSRP-based transport), so I share the concerns that Miguel already
brought up in an earlier mail. Though, had TOTE existed when we started
with file transfer draft, I'm certain we would have chosen it instead of
MSRP. We tried our best in the draft to actually decouple the
offer/answer part from the transport, envisioning that some day there
might be something like TOTE to run over. Now that the work is already
quite far and there actually are a few implementations of the draft (not
much in public, but for instance GSMA has had an interop event for
image-sharing based on the draft), it would be non-constructive to
develop file transfer with TOTE from the scratch. It would be better to
see if the O/A model could be sustained while providing an alternative
transport. 

Another concern is that it took something like over 5 years from the
start to get MSRP to RFC. How long will it take for TOTE? I already see
such risk if we get stuck in arguments about the MIME usage/negotiation
model and so on, where there's probably no clear answer, so they could
be debated forever. Yet another risk is that TOTE is already too late
and people with use cases for it are committed to something else (MSRP,
media-control stuff). So, it would be useful to probe if people really
would have use cases for it in their UA products, or would it be only of
academic interest.

So, as a summary I'm positive of going forward with TOTE, but there are
issues wrt. overlap with MSRP and the market adoption, which we need to
quantify a bit first.

Markus

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 07 Mar 2008 13:09:08 +0200

Hi,

I have to say that I completely agree with the Marcus comments.
I also think the draft is really good and useful in some scenarios,
well in a lot of scenario if we consider that nowadays NAT are everywhere.

However I also share the doubts:
we already have other mechanism in SIP that let possible to do what tote 
does.
Of course tote does them in a simpler way, however the other mechanisms 
are already out:
standardized and implemented by people and industries.
So I really think we need to discuss and consider the overlap with MSRP 
and the market adoption of
the existents mechanisms before to go ahead with this draft.

About the fact that the tote draft could convince people interested in 
IM to come back to SIP
IM and abandon XMPP, I have some doubt as well.
Of course with tote SIP becomes more and more similar to XMPP,
but XMPP is already done and we do not know how long will take the tote 
standardization.

/sal

---

From: Sean Olson <[email-masked]>
Date: Fri, 7 Mar 2008 12:46:38 -0800

Is there anything that would prevent MSRP from working over ICE/TURN?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 07, 2008 12:36 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Sip] Comments on TOTE

Hi,

Here are my views on

Markus

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 Mar 2008 13:12:25 -0500

Yes.  Currently MSRP does not support ICE, but that could be fixed I think, if we break the current binding between MSRP path URI and the TCP socket address/port, and add the ability for either side to open the connection.

The second issue is that TURN doesn't work in some (rather common) deployment models, because the address that would have to be allocated depends on where the SIP signaling goes.  It is not knowable a priori.

The third issue is that ICE isn't allowed in some (rather common) deployment models, due to security policies which require the IP Addresses of client hosts to be hidden from entities outside the trust domain.  Although this is an issue for MSRP as well.

The fourth issue is that it requires TURN servers, which are not that common, afaict, whereas App Servers are.

The fifth issue is that it adds complexity which XMPP does not have, which makes XMPP more attractive. (not that there's anything wrong with that, but you want to have as many users using the same protocol as possible, to make it worth using that protocol - Metcalfe's law basically)

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean
> Olson
> Sent: Friday, March 07, 2008 3:47 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sip] Comments on TOTE
>

---

From: Sean Olson <[email-masked]>
Date: Sat, 8 Mar 2008 11:07:55 -0800

I may be a bit biased because we are successfully using ICE/TURN today for audio/video.  It's not perfect but better than anything else we've found.  How would an app server help with the firewall traversal problem?

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Saturday, March 08, 2008 10:12 AM
To: Sean Olson; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Comments on TOTE

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 Mar 2008 22:10:31 -0500

Oh I don't doubt TURN is used, and successfully.  As far as I am aware, though, it's a drop in the bucket of the deployed SIP networks.  (of course that view could be completely wrong due to the types of customers I serve)  My understanding is one of the bigger ones that uses TURN for voip uses XMPP for IM, not MSRP.

An app server could be on the public Internet, in theory, as much as a Turn server would or web servers or whatever.  Since it is frequently terminating the TCP connection for MSRP, it could be the one being the public TCP server address for the connection from the client.  That's not to say that TURN shouldn't or wouldn't be used for MSRP, just that it's not necessary in some environments for NAT traversal.  And the more environments that can be supported, the more reachable users there will be, and the more valuable it becomes.

-hadriel

> From: Sean Olson [mailto:[email-masked]]
> Sent: Saturday, March 08, 2008 2:08 PM
> To: Hadriel Kaplan; [email-masked]; [email-masked]
> Cc: [email-masked]
> I may be a bit biased because we are successfully using ICE/TURN today for
> audio/video.  It's not perfect but better than anything else we've found.
> How would an app server help with the firewall traversal problem?
>
> Yes.  Currently MSRP does not support ICE, but that could be fixed I
> think, if we break the current binding between MSRP path URI and the TCP
> socket address/port, and add the ability for either side to open the
> connection.
>
> The second issue is that TURN doesn't work in some (rather common)
> deployment models, because the address that would have to be allocated
> depends on where the SIP signaling goes.  It is not knowable a priori.
>
> The third issue is that ICE isn't allowed in some (rather common)
> deployment models, due to security policies which require the IP Addresses
> of client hosts to be hidden from entities outside the trust domain.
> Although this is an issue for MSRP as well.
>
> The fifth issue is that it adds complexity which XMPP does not have, which
> makes XMPP more attractive. (not that there's anything wrong with that,
> but you want to have as many users using the same protocol as possible, to
> make it worth using that protocol - Metcalfe's law basically)
>
> -hadriel
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 9 Mar 2008 12:31:34 +0100

Hi,

I think MSRP would work will for ICE/TURN, without the need for
dedicated MSRP relays, if the routing was based on the SDP c/m- lines
(like normal media plane traffic) instead of the MSRP specific routing
attributes/parameters. That would also make MSRP more "SBC friendly",
because there is no need to modify information in the MSRP message
itself.

I BELIEVE (maybe someone with more information can verify) that is also
how OMA has specified usage and NAT traversal of MSRP.

Regards,

Christer 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: 9. maaliskuuta 2008 5:11
> Oh I don't doubt TURN is used, and successfully.  As far as I 
> am aware, though, it's a drop in the bucket of the deployed 
> SIP networks.  (of course that view could be completely wrong 
> due to the types of customers I serve)  My understanding is 
> one of the bigger ones that uses TURN for voip uses XMPP for 
> IM, not MSRP.
> 
> An app server could be on the public Internet, in theory, as 
> much as a Turn server would or web servers or whatever.  
> Since it is frequently terminating the TCP connection for 
> MSRP, it could be the one being the public TCP server address 
> for the connection from the client.  That's not to say that 
> TURN shouldn't or wouldn't be used for MSRP, just that it's 
> not necessary in some environments for NAT traversal.  And 
> the more environments that can be supported, the more 
> reachable users there will be, and the more valuable it becomes.
> 
> -hadriel
> 
> > I may be a bit biased because we are successfully using 
> ICE/TURN today 
> > for audio/video.  It's not perfect but better than anything 
> else we've found.
> > think, if we break the current binding between MSRP path 
> URI and the 
> > TCP socket address/port, and add the ability for either 
> side to open 
> > the connection.
> >
> > deployment models, due to security policies which require the IP 
> > Addresses of client hosts to be hidden from entities 
> outside the trust domain.
> > The fourth issue is that it requires TURN servers, which 
> are not that 
> > common, afaict, whereas App Servers are.
> >
> > The fifth issue is that it adds complexity which XMPP does 
> not have, 
> > which makes XMPP more attractive. (not that there's anything wrong 
> > with that, but you want to have as many users using the 
> same protocol 
> > as possible, to make it worth using that protocol - Metcalfe's law 
> > basically)
> >
> > -hadriel
> >
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of
> > Sean
> > > Olson
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of [email-masked]
> > > oriented transport mechanism, with a good NAT traversal 
> story. There 
> > > are many use cases for such a mechanism, so instead of 
> developing a 
> > > specific one for each of them, it is better to have a 
> common baseline.
> > > Utilization of ICE-TCP and TURN should be a basic 
> requirement here, 
> > > and TOTE is indeed using them.
> > >
> > > overhead and also the fragmentation, re-assembly and 
> reporting make 
> > > it complicated. Furthermore I'm not convinced a yet how 
> the muxing 
> > > of sessions between relays really works: Based on SIMPLE-list, at 
> > > least two
> > > (independent) implementers have tried to produce a relay 
> like that, 
> > > but have concluded that it is not doable. I don't know if other 
> > > relay implementations exist. The IMS and OMA folks prefer B2BUAs 
> > > over relays for MSRP NAT traversal, and that is the only 
> space I can 
> > > see some serious implementation/deployment of MSRP. (This 
> might be 
> > > because most people who were originally interested in SIP IM have 
> > > now switched to
> > > XMPP.) Well, I haven't seen much happening with 
> ICE/TURN-TCP either, 
> > > but that could be a chicken-and-egg problem that 
> something like TOTE 
> > > could solve. It would be of course helpful if people who came up 
> > > with MSRP relay/muxing/chunking requirements would 
> indicate if they 
> > > still see that model valid (for customers of MSRP/IM) and if they 
> > > see a lot of deployment potential for the protocol.
> > >
> > > well-defined and well-working baseline that solved some 
> hard issues 
> > > like NAT traversal, e2e security and provided some tools 
> for session 
> > > negotiation. I'd be quite liberal about the usages 
> themselves, but 
> > > of course the IETF should immediately charter 
> standards-track work 
> > > on some of the key ones.
> > >
> > > I'm co-author of draft-ietf-mmusic-file-transfer-mech 
> (file transfer 
> > > O/A and MSRP-based transport), so I share the concerns 
> that Miguel 
> > > already brought up in an earlier mail. Though, had TOTE 
> existed when 
> > > we started with file transfer draft, I'm certain we would have 
> > > chosen it instead of MSRP. We tried our best in the draft to 
> > > actually decouple the offer/answer part from the transport, 
> > > envisioning that some day there might be something like 
> TOTE to run 
> > > over. Now that the work is already quite far and there 
> actually are 
> > > a few implementations of the draft (not much in public, but for 
> > > instance GSMA has had an interop event for image-sharing based on 
> > > the draft), it would be non-constructive to develop file transfer 
> > > with TOTE from the scratch. It would be better to see if the O/A 
> > > model could be sustained while providing an alternative transport.
> > >
> > > start to get MSRP to RFC. How long will it take for TOTE? 
> I already 
> > > see such risk if we get stuck in arguments about the MIME 
> > > usage/negotiation model and so on, where there's probably 
> no clear 
> > > answer, so they could be debated forever. Yet another 
> risk is that 
> > > TOTE is already too late and people with use cases for it are 
> > > committed to something else (MSRP, media-control stuff). So, it 
> > > would be useful to probe if people really would have use 
> cases for 
> > > it in their UA products, or would it be only of academic interest.
> > >
> > > So, as a summary I'm positive of going forward with TOTE, 
> but there 
> > > are issues wrt. overlap with MSRP and the market 
> adoption, which we 
> > > need to quantify a bit first.
> > >
> > > Markus
> > >
> > >
> > >
> > >
> > >
> > > This list is for NEW development of the core SIP Protocol Use 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments on the application of sip 
> > > This list is for NEW development of the core SIP Protocol Use 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments on the application of sip
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 9 Mar 2008 11:27:08 -0400

[this is actually a discussion that belongs in simple, but oh well]

I would agree with you - we thought the same thing.  But my customers are telling me otherwise.

-hadriel

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Sunday, March 09, 2008 7:32 AM
> To: Hadriel Kaplan; Sean Olson; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sip] Comments on TOTE
>
>
> Hi,
>