Subject: [Sip] Comments to the TOTE draft

From: Miguel Garcia <[email-masked]>
Date: Wed, 27 Feb 2008 13:19:12 +0200

Here are some comments to the TOTE draft:

1. In the Introduction the draft mentions three general purpose 
mechanisms that allow a pair of agents to communicate data during a 
session. However it fails to name the most relevant work for this draft, 
which is the file transfer mechanism, an MMUSIC WG item:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-06.txt

2. Then, I believe most of what the draft proposes can be done with the 
above draft. For good or for bad, the file transfer mechanism does not 
really define a new file transfer protocol as TOTE does, but reuses the 
existing MSRP.

3. I don't think I have seen the requirements for this draft. So, I 
cannot really evaluate why the file transfer mechanism is able to meet 
these requirements, and I cannot evaluate if MSRP is able to meet these 
requirements. The requirements corresponding to the file transfer 
mechanism were posted way back in this draft:
http://tools.ietf.org/draft/draft-isomaki-sipping-file-transfer/draft-isomaki-sipping-file-transfer-01.txt

4. Assuming that there is a need for a new protocol for transferring 
files between to endpoints, I would encourage to re-use existing work. 
In particular, the file transfer mechanism says:

       In principle it is possible to use the SDP extensions defined here
       and replace MSRP with any other similar protocol that can carry
       MIME objects.  This kind of specification can be written as a
       separate document if the need arises.  Essentially, such protocol
       should be able to be negotiated on an SDP offer/answer exchange
       (RFC 3264 [RFC3264]), be able to carry MIME objects between two
       endpoints, and use a reliable transport protocol (e.g., TCP).

For what I read, TOTE will qualify for such alternative protocol, but 
again, we need to understand the requirements that makes the need for 
yet another file transfer protocol.

5. On a slightly different topic. The draft also mentions Shared 
Browsing. I have recently put a draft that describes how to do 
collaboration between endpoints, and one of the topics is Shared 
Browsing. The draft is this one:

http://www.ietf.org/internet-drafts/draft-garcia-mmusic-sdp-collaboration-00.txt

Section 4.2 discusses the topic, and proposes to use the file transfer 
mechanism for sending those URL objects between endpoints.

6. I've been told that in German language TOTE means DEATH, so, perhaps 
that name should be changed.

So, all in all, I think we need more discussion on the requirements with 
respect existing work, and try to identify the delta that makes the need 
for this draft.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Feb 2008 16:56:54 -0500

Thanks for the comments, Miguel. Looks like this topic is a contentious 
one, for different reasons than I thought. Lots of folks didn't want 
info-events, but it looks like lots of folks think we already have 
solutions for the media-plane equivalent (file transfer and the 
media-ctrl framework).

Responses below:

> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-06.txt 

Sure I am aware of that. I saw that as a specific type of data 
communications - file transfer.

> really define a new file transfer protocol as TOTE does, but reuses the 

I think its the MIME bit that has gotten lots of folks in a tizzy here. 
I think, you are thinking, "MIME object = file" and so this draft is 
basically doing file transfer. But really its about these "purposes", 
and a purpose can be a mini-protocol and not really a file transfer in 
any sense of the word. Would you use the file transfer draft above to 
exchange camera controls? I didnt think so.

> http://tools.ietf.org/draft/draft-isomaki-sipping-file-transfer/draft-isomaki-sipping-file-transfer-01.txt 

The requirements are the same ones driving info-events - the ability to 
communicate between agents for new applications without requiring 
standardization work. I am merely adding a media-path solution to that 
problem.

> files

TOTE is not about file transfer. See above.

> between to endpoints, I would encourage to re-use existing work. 

Interesting. I had missed that bit of the document.

So I think there are a few ways to see how these relate:

1. as you suggest, TOTE could be an alternative to MSRP and you could 
continue to use the SDP attributes defined in your draft,

2. the file transfer spec very much couples the negotiation of the file 
transfer itself (parameters of the file along with an indication of 
willingness) with O/A. We have been burned by this before, when we've 
tried to take negotiation things and couple them to the O/A exchange. 
Security key negotiation is an example. We found, in the end, by doing 
it in the media path we had more flexibility and were not limited to a 
two-way handshake. So another way to think of it, is this, would you 
benefit from separating the file transfer negotiation from O/A itself? 
Would you benefit from more round trips or more complex objects that are 
hard to place in SDP? I for one always thought file trnasfer is best 
done as a 4-way:

A->B want to send file, here are characteristics
B->A yes, please send
A->B ok here is the file
B->A got it

basically the file transfer is doing the first two in O/A and the last 
two in MSRP, so it kind of works. But I wonder if you had more 
flexibility would we get a feature or capability that would be 
impossible otherwise. For example, the ability of the recipient to 
cancel mid-transaction, or to tell the sender to pause and resume. If we 
went this route, you'd basically take your existing SDP attributes, take 
them out into a standalone protocol message and send e2e over this 
connection instead.

3. file transfer is for file transfer and tote is for other things that 
don't include file transfer; i.e., these look similar but file transfer 
has some special needs and that is why we have a specific spec for it. 
And so both proceed independently.

Architecturally, the interesting question I'm posing, is what is our 
model for extending SIP to accomodate new media-level things. To date, 
it has been about doing SDP extensions for each new thing. This draft 
suggests that we don't do that; that we make SIP/SDP minimal and just 
set up something else that can do the application-specific protocol 
procedures that are optimized for it. This means, you don't need to 
upgrade your SIP/SDP infrastructure (since with b2bua they are coupled) 
every time you want something new. This is the same aspect that has 
attracted people to INFO - I can send new stuff without a new sip 
extension. I'd like the same for the media plane.

> mechanism for sending those URL objects between endpoints.

Yes I did see this, and had a chance to skim. Looking forward to the 
discussion.

> that name should be changed.

lol. Well TOTE worked really nice in English since it means, "to carry" 
and that is basically what this does.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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: Miguel Garcia <[email-masked]>
Date: Thu, 28 Feb 2008 11:37:39 +0200

Inline discussion.

Jonathan Rosenberg wrote:
>> session. However it fails to name the most relevant work for this 
>> draft, which is the file transfer mechanism, an MMUSIC WG item:

That is correct, the draft is specific to file transfer. Now, I don't 
want to open a discussion about what is a file versus what is a MIME 
object. I think we should focus on the semantics, and what make the file 
transfer draft not feasible for the TOTE protocol.

> 
>>
>>
>> 2. Then, I believe most of what the draft proposes can be done with 
>> the above draft. For good or for bad, the file transfer mechanism does 
>> not really define a new file transfer protocol as TOTE does, but 
>> reuses the existing MSRP.
> 

If it is about a single camera control then it is possible to do it. But 
if the camera control is some sort of continuous interaction, then I 
would probably not use the file transfer, but just vanilla MSRP with the 
appropriate content type.

>> these requirements, and I cannot evaluate if MSRP is able to meet 
>> these requirements. The requirements corresponding to the file 
>> transfer mechanism were posted way back in this draft:

ok, understood.

>> between to endpoints, I would encourage to re-use existing work. In 
>> particular, the file transfer mechanism says:
>>

Yes, the background for the file transfer draft. It tries to emulate the 
  file transfer feature that we have in many instant messaging systems. 
So, the coupling of the file description with the O/A works well in that 
case. Any of both ends can also abort the file transfer. Both ends can 
also pause and resume the file transfer.

> And so both proceed independently.

I think the OTE draft should reuse the file transfer draft as much as it 
could. Dealing with files or MIME objects is a subtle difference. 
Perhaps the biggest difference is that TOTE tries to create a media 
stream for transferring a MIME object, while the file transfer draft 
assume a given protocol (so far MSRP) and a given purpose (a file). But 
it should be possible for me to offer you a file with either MSRP or the 
simple TCP connection that TOTE uses without much changes to the SDP.

> extension. I'd like the same for the media plane.

This is certainly the question. But even with the model that TOTE uses, 
you still need to at least register the MIME objects or the underlying 
protocol, right? I understand the SDP should not change for any of these 
usages that you envision, so you don't need to upgrade intermediaries, 
but at least some mnemonic that identifies the protocol should be

/Miguel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Feb 2008 09:42:09 -0500

inline:

Miguel Garcia wrote:

>> I think its the MIME bit that has gotten lots of folks in a tizzy 
>> here. I think, you are thinking, "MIME object = file" and so this 
>> draft is basically doing file transfer. But really its about these 
>> "purposes", and a purpose can be a mini-protocol and not really a file 
>> transfer in any sense of the word. Would you use the file transfer 
>> draft above to exchange camera controls? I didnt think so.
> 

Ah, so there are two parts of this discussion:

1. whether MSRP is to be used as a general transport of stuff between 
agents, which is not strictly instant messaging (like camera controls)

2. regardless of MSRP vs. something else, when would one use the file 
transfer mechanism and when not

Frankly I don't think you'd ever use the file transfer mechanism for 
camera controls, even a one-shot. Most of the file selector attributes 
don't make sense here - size, filename, hashes - these are useful 
primarily for transfering an existing stored file, not for carrying 
arbitrary protocols.

So then the question is, is MSRP a general purpose UA to UA transport 
mechanism, or not. Frankly I think it is not. Its designed around 
instant messaging which is a particular application. ITs having 
extensions for things like nicknames and conferencing which are specific 
to IM. The reporting feature is also IMHO very much an IM-specific thing.

File transfer is arguably very close to IM and can benefit from much of 
what MSRP provides; chunking and interruption all make sense because 
these are big objects.

TOTE proposes a much more lightweight transfer mechanism for general UA 
to UA protocols/applications.

>
>> 2. the file transfer spec very much couples the negotiation of the 
>> file transfer itself (parameters of the file along with an indication 
>> of willingness) with O/A. We have been burned by this before, when 
>> we've tried to take negotiation things and couple them to the O/A 
>> exchange. Security key negotiation is an example. We found, in the 
>> end, by doing it in the media path we had more flexibility and were 
>> not limited to a two-way handshake. So another way to think of it, is 
>> this, would you benefit from separating the file transfer negotiation 
>> from O/A itself? Would you benefit from more round trips or more 
>> complex objects that are hard to place in SDP? I for one always 
>> thought file trnasfer is best done as a 4-way:
>>
>> cancel mid-transaction, or to tell the sender to pause and resume. If 
>> we went this route, you'd basically take your existing SDP attributes, 
>> take them out into a standalone protocol message and send e2e over 
>> this connection instead.
> 

How do you do pause with MSRP? Specifically, how does the receiver tell 
the sender to pause? How does the receiver cancel?

> 
>>
>> 3. file transfer is for file transfer and tote is for other things 
>> that don't include file transfer; i.e., these look similar but file 
>> transfer has some special needs and that is why we have a specific 
>> spec for it. And so both proceed independently.
>>
> 

That last sentence I agree with. However What I don't agree with, is if 
I am not transferring a file, just doing a camera control or somethign, 
that I have to use the file transfer SDP attributes.

-Jonathan R.

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 28 Feb 2008 17:33:01 +0200

Inline as well.

> transfer mechanism and when not

Right, that is correct. Besides, I think the general willingness of 
making implementor's life easy, so that if we end up having several 
orthogonal mechanisms that share some sort of commonality, all these 
mechanism should be able to coexist in an implementation.

> primarily for transfering an existing stored file, not for carrying 

I think I concluded the same, but with different reasons. I think camera 
control is probably a stream of actions, so you move the camera up, pan, 
tilt, zoom, etc. Let's assume that you model each action in an XML 
document. I wouldn't use the O/A described in the file transfer draft, 
because you would need to re-INVITE prior to sending each action, get 
acceptance from the remote party (the camera), and then do the action. 
It will be annoying, with a tremendous overhead (re-INVITE), and far 
from real-time.

However, you can easily create a regular MSRP channel where you 
transport those MIME objects. MSRP can carry any MIME object of any 
arbitrary length, so, it meets the needs. The discussion of MSRP/not 
MSRP is below.

> to IM. The reporting feature is also IMHO very much an IM-specific thing.

I disagree here. You said:
- It is designed around instant messaging: I would say MSRP is designed 
around real-time transfer of objects. The MSRP draft provides examples 
and provisions for transferring, for example, large video files.
- It's having extensions for things like nicknames and conferencing 
which are specific to conferencing: I don't see the point here. It is 
like if you tell me that SIP is not good for voice because there are 
extensions for presence, instant messaging and alike. MSRP is generic 
enough to carry objects between two points. Extensions try to improve 
the user experience for specific applications.

> what MSRP provides; chunking and interruption all make sense because 

Agreed.

> to UA protocols/applications.

And I don't object it. As I indicated earlier, the use case for the file 
transfer is: I have an instant messaging application that implements 
MSRP. Now you are probably saying: does it mean I need to implement MSRP 
for a trivial file sending. The answer is no, and I don't have any 
problem with the simple trivial protocol that the TOTE draft describes.

>>> basically the file transfer is doing the first two in O/A and the 
>>> last two in MSRP, so it kind of works. But I wonder if you had more 
>>> we went this route, you'd basically take your existing SDP 
>>> attributes, take them out into a standalone protocol message and send 
>>> e2e over this connection instead.
>>
>> Yes, the background for the file transfer draft. It tries to emulate 
>> the  file transfer feature that we have in many instant messaging 
>> systems. So, the coupling of the file description with the O/A works 
>> well in that case. Any of both ends can also abort the file transfer. 
>> Both ends can also pause and resume the file transfer.
> 

Pause from receiver to sender: re-INVITE with SDP offer with the MSRP 
media stream set to inactive.

Cancel from receiver: re-INVITE with SDP offer setting the MSRP media 
stream to port 0.

>> I think the OTE draft should reuse the file transfer draft as much as 
>> it could. Dealing with files or MIME objects is a subtle difference. 
>> assume a given protocol (so far MSRP) and a given purpose (a file). 
>> But it should be possible for me to offer you a file with either MSRP 
>> or the simple TCP connection that TOTE uses without much changes to 
>> the SDP.
> 

I said "as much as it could", meaning that re-using or adapting already 
defined SDP parameters.

/Miguel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Feb 2008 11:53:33 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Miguel Garcia
>
> >

Not really.  We *DO* say SIP is not appropriate for carrying the voice itself (vs. RTP), or not appropriate for carrying session-based IM (vs. MSRP).  We say that because of SIP's properties compared to the needs/properties of voice or IM or whatever.  I assume we all agree on that.

MSRP also has properties.  Some of them frankly aren't very good for bulk file transfer, IMHO.  One of those "properties" is it doesn't seem to be getting deployed UA-UA.  It's getting deployed UA-AS-AS-UA, where "AS" is an app server or SBC or both either acting as an MSRP-relay or MSRP-b2bua.  (it shouldn't be a surprise this is happening - the MSRP protocol leaves no other choice)

I don't think it's a good property that a bulk file transfer gets sent through a chain of app servers.  I don't think it's a good property that camera controls get sent through a chain of app servers.  My 2 cents anyway.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Feb 2008 13:09:14 -0500

Just jumping in, not replying to anyone in particular...

I don't see the relationship between TOTE-like functionality and File 
Transfer at all. But I do see MSRP as an alternative to TOTE for the 
kinds of things Jonathan is proposing TOTE for.

Advantages of using MSRP are:
- its already defined
- it already has all the mime type negotiation defined
- it has some mechanisms to mitigate the head of line blocking issue
- whatever is done to get MSRP through firewalls and proxies
   could be reused for this application
- the exchange of mime objects as envisioned for tote could
   share a connection with IM if IM happens to be in use

Some disadvantages:
- its heavier weight than what Jonathan is proposing
- there may be issues with MSRP relays

The heavier weight of MSRP is an issue for UAs that won't otherwise be 
implementing MSRP anyway. For those that do its probably not an issue. 
OTOH, more uses for the protocol may serve to encourage ubiquitous 
implementation.

The use of relays vs using ICE to get though FWs and NATs has already 
been brought up for MSRP in general I think. Perhaps that needs to be 
considered.

OTOH, the use of media intermediaries of one sort or another for MSRP is 
likely to be required in many cases, at least in enterprises, because 
they have a need to log the stuff for legal or other business reasons. 
It may well be that the same people would conclude that they need to log 
TOTE exchanges too, because it otherwise might be used to tunnel things. 
So it may be that e2e media connections won't be allowed in any case.

Bottom line: I haven't yet decided if I like TOTE or would prefer to see 
MSRP used for that purpose.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Feb 2008 13:54:17 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, February 28, 2008 1:09 PM
>
> ...

MSRP needs that because it creates the problem for itself (or rather allows it to happen), because it lets multiple logical use or user connections be aggregated into one TCP connection.  I'm not saying that's good/bad, but for TOTE that wouldn't be an issue needing to be solved, afaict.

> OTOH, more uses for the protocol may serve to encourage ubiquitous

If the idea is to provide a media-path-channel alternative for some of the more media-applicable uses of INFO in the wild, the hurdle of MSRP would be immense.  Making vendors choose between either implementing SIP+INFO, or SIP+MSRP?  That's not a hard choice to choose from, and they'll choose poorly.

> So it may be that e2e media connections won't be allowed in any case.

I have no doubt that would be needed in some cases, maybe even most cases.  There is, however, a HUGE difference between *monitoring* TCP stream data payload contents, and *modifying* TCP stream data payload contents.  MSRP requires modifying, even just for NAT traversal (today).  Some vendors have started to implement proprietary extensions, to avoid that.  That's not a good thing.

-hadriel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Feb 2008 15:16:05 -0500

inline:

Hadriel Kaplan wrote:
> 
>> -----Original Message----- From: Paul Kyzivat
>> [mailto:[email-masked]] Sent: Thursday, February 28, 2008 1:09
>> PM
>> 
>> Advantages of using MSRP are: ... - it has some mechanisms to
>> mitigate the head of line blocking issue
> 
> MSRP needs that because it creates the problem for itself (or rather
> allows it to happen), because it lets multiple logical use or user
> connections be aggregated into one TCP connection.  I'm not saying
> that's good/bad, but for TOTE that wouldn't be an issue needing to be
> solved, afaict.

Correct. There is no sharing of connections between users, so any HOL 
blocking is caused by a user's own problem. This is why the draft says 
to, based on purpose, use different params. So basically tote lets the 
transport layer solve all these problems.

> 
> 
>> The heavier weight of MSRP is an issue for UAs that won't otherwise
>> be implementing MSRP anyway. For those that do its probably not an
>> issue. OTOH, more uses for the protocol may serve to encourage
>> ubiquitous implementation.
> 
> If the idea is to provide a media-path-channel alternative for some
> of the more media-applicable uses of INFO in the wild, the hurdle of
> MSRP would be immense.  Making vendors choose between either
> implementing SIP+INFO, or SIP+MSRP?  That's not a hard choice to
> choose from, and they'll choose poorly.

Yup. Thats why I wanted that "T" in TOTE to be "Trivial".

> 
> 
>> OTOH, the use of media intermediaries of one sort or another for
>> MSRP is likely to be required in many cases, at least in
>> enterprises, because they have a need to log the stuff for legal or
>> other business reasons. It may well be that the same people would
>> conclude that they need to log TOTE exchanges too, because it
>> otherwise might be used to tunnel things. So it may be that e2e
>> media connections won't be allowed in any case.
> 
> I have no doubt that would be needed in some cases, maybe even most
> cases.  There is, however, a HUGE difference between *monitoring* TCP
> stream data payload contents, and *modifying* TCP stream data payload
> contents.  MSRP requires modifying, even just for NAT traversal
> (today).  Some vendors have started to implement proprietary
> extensions, to avoid that.  That's not a good thing.

TOTE would not; you could just insert in the middle of the tcp 
connection and shovel data back and forth without ever looking at the 
payload.

Again the idea is to do this in a way that, we can easily add new 
applications in the future without infrastructure change. So having a 
way to do e2e, SBCs, etc. really easy, and just ONCE, was important.

-Jonathan R.

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Feb 2008 14:25:12 -0600

> Cancel from receiver: re-INVITE with SDP offer setting the MSRP media 

This is getting off-topic, but I'm a bit concerned about using 
sledgehammers where screwdrivers are warranted.

For canceling a file transfer -- that is, a single MIME object -- you're 
better off using the approach described in section 10.5 of RFC 4975. 
Otherwise, you're running the risk of throwing out an ongoing IM session 
just because you don't want to complete a specific file transfer.

In the pause case, I agree that putting the MSRP stream on hold is a 
valid way to convey the semantics of, "I want you to pause everything 
inside this MSRP session," including the file transfer, but by no means 
limited to it. For most IM-related use cases, it would seem that this is 
very unlikely to be what the user expects, wants, or is even willing to 
put up with.

For example: imagine that we're in an IM session using a client designed 
as you propose above. You start sending me a 5 Mb file. A dialog box 
pops up on my screen that conveys the progress of this file; it contains 
two buttons: [Pause], and [Cancel]. I press the button marked "Pause," 
and the file stops arriving. And suddenly you stop responding to my 
instant messages. Perhaps I manage to guess that the IM session has 
frozen because I paused the file transfer. So, to fix this, I press 
[Cancel]. And the whole IM window just goes away.

/a

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 29 Feb 2008 11:45:12 +0200

> just because you don't want to complete a specific file transfer.

Point taken, I agree with it. I think we will add this and other 
clarifications to the file transfer draft.

> very unlikely to be what the user expects, wants, or is even willing to 

Notice that the file transfer draft requires a single MSRP session for 
file transfer, so pausing the MSRP session will only have effect on the 
file transfer. In any case, I agree on the benefits of using the 413 
response.

> [Cancel]. And the whole IM window just goes away.

As I said, this wouldn't happen with any of the proposals, because the 
MSRP session of the file transfer is different from that of the instant 
messaging.

/Miguel