Subject: [MMUSIC] Re: draft-ietf-mmusic-file-transfer-mech-04

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Oct 2007 13:39:08 -0400

I started reviewing this version with the expectation that all issues 
were now resolved. But as I started thinking about the mechanism for 
handling subsequent o/a when no new transfer is required, and began to 
see potential problems - some new ones and some that have been there.

First, 4975 still is operable here, right? (This just provides layered 
behavior on top of that.) That means that the o/a rules for 4975 still 
apply. IIUC this means that in a subsequent o/a (after previously 
negotiating an MSRP session) its possible that the connection will be 
replaced with a new one. In fact, if the new o/a is in the opposite 
direction, its mandated that a new connection be made in the opposite 
direction.

(I just posted a question to SIMPLE about how MSRP is supposed to behave 
in this case.)

Now, getting on to the draft, the file-transfer-id is dealing with 
instances of file transfers, not of MSRP sessions. I *assume* that a 
file transfer will be completed on one connection - that it won't be 
split across multiple connections - or is that a bad assumption? (I 
think if it can't be completed in a single connection then it will need 
to be restarted, perhaps with a file-range.)

So, suppose a file transfer is started, and then before it completes 
there is need to send a new o/a. (Perhaps because of session timer.) 
This could conceivably result in a new MSRP session being established in 
the other direction. Does that cause the file transfer to abort in the 
middle? Or does the file transfer continue on the original connection 
until it is complete or until the connection fails?

If the transfer continues until complete, then a clean way to handle a 
new offer that doesn't want to initiate a new transfer would simply be 
to set the port=0 in the m-line, avoiding creating a new connection that 
isn't needed.

But if the old connection must be torn down before transfer is complete, 
then we have a bigger problem.

I've got some lesser issues, but will defer discussing them until this 
is clarified.

	Thanks,
	Paul

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 31 Oct 2007 14:12:25 +0200

Hi Paul:

Thanks for your comments. See inline.

Paul Kyzivat wrote:
> First, 4975 still is operable here, right? 

Yes, correct. MSRP (RFC 4975) is the foundation for this draft.

> (This just provides layered 

Certainly we need to clarify the MSRP behavior in SIMPLE. My 
understanding is that TCP connections are decoupled from MSRP sessions. 
I based this comment on the fact that several MSRP sessions can share a 
single TCP connection, something that wouldn't be possible if we follow 
your assumptions.

> to be restarted, perhaps with a file-range.)

What you said is correct. A file transfer will complete on a single TCP 
connection. As you mentioned, file transfers can be interrupted. If the 
file transfer is resumed at a later time, it will be a different one and 
the file-range will signal the starting point.

> This could 2result in a new MSRP session being established in 
> the other direction. 

Hang on... If it is a new O/A due to session timer, or adding additional 
media streams, the SDP-for-MRSP won't change. Thus, the MSRP session 
will remain as with previous O/A

However, if the SDP-for-MSRP changes the MSRP session, then it implies a 
different file transfer. This is covered in the first paragraph of 
Section 8.6 of the file transfer draft.

> Does that cause the file transfer to abort in the 

Did the 'file-transfer-id' change or not?
This is discussed in Section 8.3 of the draft.

- If the file-transfer-id changed and the MSRP session did not change, 
then it means "abort the current transfer and restart".

- If the both the file-transfer-id the MSRP session changed, then it 
means "abort the current transfer and start a new file transfer". So, 
the file descriptor has changed as well.

- If neither the file-transfer-id nor the MSRP session changed, then it 
means "do nothing, continue as we are currently doing".

- If the file-transfer-id did not change, but the MSRP session changed, 
then is also means "do nothing, continue as we are currently doing". 
This is because MSRP allows to do a new SDP o/a, change the MSRP 
sessions, and continue as if nothing had happened. I don't know what is 
the real use case behind, but this seems to be how MSRP works.

> to set the port=0 in the m-line, avoiding creating a new connection that 

We still allow port=0, but this is a mechanism used, for example, to 
reject a media stream. Port=0 means "I don't want to establish this 
media stream", and applies for MSRP as well. So, we shouldn't overload 
the term to say "I want to remain the media stream (MSRP session) but 
don't send me media (the file)."

> then we have a bigger problem.

Well, I think the file-transfer-id serves for that purpose.

> I've got some lesser issues, but will defer discussing them until this 

/Miguel

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Oct 2007 12:26:17 -0400

Miguel - inline.

Miguel Garcia wrote:
>> (This just provides layered behavior on top of that.) That means that 
>> the o/a rules for 4975 still apply. IIUC this means that in a 
>> subsequent o/a (after previously negotiating an MSRP session) its 
>> possible that the connection will be replaced with a new one. In fact, 
>> if the new o/a is in the opposite direction, its mandated that a new 
>> connection be made in the opposite direction.
> 

Yes, I know this has been asserted, and its certainly desirable. I'm 
just having difficulty finding an explanation of this behavior. All I 
can find is a statement that the offerer is expected to initiate the 
connection. It doesn't say (AFAIK) that it should only do so if there 
isn't already a connection.

>> (I just posted a question to SIMPLE about how MSRP is supposed to 
>> behave in this case.)

I haven't gotten any responses there yet. Hopefully I've just missed 
something, or else a clarification will deal with it.

Its reasonable to assume that there must be some way to do another o/a 
without disturbing an existing MSRP session.

>> think if it can't be completed in a single connection then it will 
>> need to be restarted, perhaps with a file-range.)
> 
>> This could 2result in a new MSRP session being established in the 
>> other direction. 
> 

I don't see how to draw that conclusion from the paragraph. It says that 
you can only send one file using the MSRP session, nothing more. (The 
*end* of section 8.6 says that the MSRP session should be closed when 
the transfer is complete, which of course precludes reusing it for an 
additional transfer.)

I see nothing addressing the behavior if the MSRP parameters should 
change but the file transfer id remains unchanged. I can imagine three 
possibilities:

1) the transfer is aborted if it hasn't already completed. The use of 
the same file transfer id with a different session is ignored.

2) the use of the same file transfer id with a different session is 
considered an error. The request carrying the offer is rejected. The 
transfer continues on the same session if it hasn't already completed.

3) the transfer is continued transparently on the new MSRP session.

Of those, (3) seems most desirable, but I expect it is fraught with 
implementation problems. (1) is probably the easiest to implement.

If this behavior is considered an error case then perhaps we don't need 
to concern ourselves with how it is handled. But if doing a new O/A 
without a change to SDP can still result in a new session then that has 
the same resolutions as above and isn't an error case.

>> Does that cause the file transfer to abort in the middle? Or does the 
>> file transfer continue on the original connection until it is complete 
>> or until the connection fails?

Assume the original INVITE that established the file transfer was from 
Alice to Bob, and the offer was in the invite.

What I had in mind was:

- The new INVITE, and offer, is from Bob to Alice

- The part of the offer from Bob relating to the file transfer is
   identical to what Bob sent in his prior answer.

- The part of the answer from Alice relating to the file transfer
   is identical to what Alice sent Bob in her prior offer.

> Did the 'file-transfer-id' change or not?

No.

> means "do nothing, continue as we are currently doing".

In my scenario this all works IF the session doesn't have to be 
reestablished in the other direction because the new offer came from Bob 
while the old offer came from Alice. Its really an MSRP question. You 
have assumed that no new session is required. Its a reasonable 
expectation. I just want to get clarification on it over in SIMPLE.

> the real use case behind, but this seems to be how MSRP works.

Hmm. Where did you find that in MSRP?

With media sessions in general, viewed as streams, I think it is 
generally the case that you can continue doing what you were doing 
across a change as long as the two endpoints remain unchanged.

If you and I are talking, it is possible that our phones might need to 
negotiate a new RTP stream, but we can keep talking across the change, 
though there might be a glitch. Presumably the same is true for an 
interactive MSRP session. During the switch it is again possible that 
there might be a glitch and a message be lost or duplicated, but the 
users will probably grumble and cope.

What will happen with a file transfer? Will it manage, without losing 
any of the file? Or is this case just declared illegal for file transfer?

>> to set the port=0 in the m-line, avoiding creating a new connection 
>> that isn't needed.
> 

Yes, this was a bad suggestion.

	Thanks,
	Paul

>>
>> But if the old connection must be torn down before transfer is 
>> complete, then we have a bigger problem.
>