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

From: Miguel Garcia <[email-masked]>
Date: Thu, 01 Nov 2007 10:32:12 +0200

Paul:

Inline comments . I have removed a few points that do not need further 
discussion.

Paul Kyzivat wrote:
> Miguel - inline.
> 
>>> 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.)
>>
>> 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.
>>
>>>
>>> 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 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.
> 
> 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. 

Ok, so we can try to clarify the behavior. For me, it is implicitly 
written, but if it is not clear, we will clarify.

I proposed to change the existing first paragraph in Section 8.6 to become:

    The file transfer service specified in this document uses "m=" lines
    to describe the unidirectional transfer of a file.  Consequently,
    each MSRP session established following the procedures in Section 8.1
    and Section 8.2 is used to transfer a single file.  So, senders
    MUST only use the dedicated MSRP session to send the file described
    in the SDP offer or answer.  That is, senders MUST NOT reuse an
    an existing MSRP session to create additional SDP descriptions
    of other files.

    If an SDP offer wants to send another file, it MAY re-use an existing
    m= line in SDP or it MAY create a new m= line. The former terminates
    any potential ongoing file transfer. In both cases, the SDP offerer
    MUST generate a new 'file-transfer-id' attribute and MUST create a
    new MSRP session (different from any existing one).

    If an SDP answerer receives SDP containing an existing
    'file-transfer-id' value, but the rest of the file transfer
    attributes are not the same as in a previous SDP exchange, then this
    is a protocol error, and the SDP answerer SHOULD reject the offer,
    according to regular SDP procedures. The existing session remains
    unmodified. If there was an ongoing file transfer in progress, it
    is not affected.

Comments?

> 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.
> 

According to the text above, I think this is option 2, it is a protocol 
error. The file-transfer-id changes on every new file transfer, and file 
transfers are parametrized with SDP. So, if something in the SDP related 
to the file transfer changes, then the file-transfer-id must change, 
otherwise we are discussing a protocol error.

> 
>>> 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.
> 
>> 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".
> 
> 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.

Ok, let's wait for SIMPLE to answer the question. The assumption is that 
the ongoing session is not disturbed if nothing changes.

> 
>> - 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.
> 

Note that I am going to eat my own words... the above text contradicts 
my own proposal for Section 8.6.

After re-reading MSRP and thinking a bit more, I believe simplest thing 
for the file transfer draft is to continue with the current behavior of 
"a single MSRP session maps to one-to-one to a file-transfer-id".

> Hmm. Where did you find that in MSRP?

Section 8.4 in RFC 4975, the second paragraph discusses updated SDP 
offers and the possibility to get new paths (so, including new MSRP 
sessions):

    Either peer may initiate an updated exchange at any time.  The
    endpoint that sends the new offer assumes the role of offerer for all
    purposes.  The answerer MUST respond with a path attribute that
    represents a valid path to itself at the time of the updated
    exchange.  This new path may be the same as its previous path, but
    may be different.  The new offerer MUST NOT assume that the peer will
    answer with the same path it used previously.

Although the protocol allows to change the path, it would be interesting 
to know what is the use case here. Perhaps some sort of transfer of the 
session to a different endpoint...

> 
> 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.

Right... It would help to understand the use case, and see if it makes 
sense for file transfer. For example, I don't think it makes sense to 
transfer the session to a different endpoint when a file transfer is in 
progress. The new endpoint will not get a complete usable file.

> 
> 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?

For the sake of simplicity, and keeping our feet on real non-theoretical 
use cases, we shouldn't allow to move the session to third endpoint 
while a file transfer is taking place.

/Miguel

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Nov 2007 10:49:25 -0400

Miguel Garcia wrote:
>>> 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.
>>
>> 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.)
>>

>    new MSRP session (different from any existing one).

I guess originally you were trying to arrange it so that a single MSRP 
session could be reused sequentially to transfer multiple files. That 
certainly seemed like a good ideal. And I in no way desire to break that 
behavior. I've only been trying to wring out ambiguities in the spec.

Making the reasonable assumption that it should be possible to do an o/a 
that leaves an existing MSRP session unchanged, then that goal would 
hopefully be achievable. But if putting this constraint in is the way to 
fix other issues then so be it. I haven't got my head around why were so 
strict here. More below.

>    unmodified. If there was an ongoing file transfer in progress, it

I think this last paragraph resolves the issue.

> Comments?
> 
>> I can imagine three possibilities:
>>
>> 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.
>>
> 

OK.

>>
>>>> Does that cause the file transfer to abort in the middle? Or does 
>>>> the file transfer continue on the original connection until it is 
>>> - If the file-transfer-id changed and the MSRP session did not 
>>> change, then it means "abort the current transfer and restart".
>>>
>> 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 

Yes, that seems right. Ben told me he is looking at it.

> "a single MSRP session maps to one-to-one to a file-transfer-id".

I think you can impose the rule:

- a single file-transfer-id maps to one MSRP session
   (which avoids the issues of continuing one across multiple sessions)

without imposing the inverse rule:

- a single MSRP session maps to (at most) one file-transfer-id.

I may not have thought it through sufficiently, but I don't see major 
problems with skipping this rule. The only problem I can think of is 
that the new o/a with a changed file-transfer-id, is negotiated while 
the prior transfer is still incomplete. In that case is the prior one 
aborted, or allowed to finish before the new one begins? I think there 
are some race conditions there, and a potential for the two ends to 
disagree on what to do. But that requires further analysis. I expect a 
suitable set of definitions can produce a reasonable and unambiguous result.

> session to a different endpoint...

There are lots of different cases. From the point of view of the offerer 
it is futile to speculate about *why*.

Two that come to mind as real world cases are:

- as you mention - a transfer. 3pcc can easily result in a transfer
   looking like this.

- network connectivity issues. Movement from one access network to another.

In particular its in general impossible for the offerer to know if it is 
communicating with the same entity before and after, or what context is 
shared.

> progress. The new endpoint will not get a complete usable file.

It would require an entity that preserves context about the file 
transfer to be controlling the session before and after.

The access network change is the most plausible case for this. But I 
think a application doing the file transfer could handle that by 
assuming the transfer aborted across the change. It can be restarted 
with a range on a new session. This can still be invisible to the end user.

The case that concerned me was if a new session was forced for an o/a 
that tried not to change anything. Assuming we get that clarified then 
aborting on a session change seems reasonable to me.

> while a file transfer is taking place.

For reasons above I agree.

I think these issues are now well in hand. So I will go back to lesser 
issues. That will be a separate message, later.

	Thanks,
	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 02 Nov 2007 10:10:42 +0200

Paul:

I think we are in agreement, and I've got a few ideas for how to revise 
the draft. I think I agree with you in all the issues. Let me discuss 

>> Although the protocol allows to change the path, it would be 
>> interesting to know what is the use case here. Perhaps some sort of 
>> transfer of the session to a different endpoint...
> 

I think the network connectivity requires a re-INVITE with a new 
file-range... In other words: the existing file transfer session is 
dropped and a new file transfer session (with file-range) is created. 
These are two different file-transfer-ids.

I will add some discussion in the draft.

/Miguel