Subject: RE: [Simple] MSRP: DSN lifetime open issue

From: "Chris Boulton" <[email-masked]>
Date: Fri, 16 Apr 2004 14:16:53 +0100

I agree with Hisham - If you want to save resources, some form of MSRP
termination will be required ELSE we leave this open to the
implementation of the client.  Either they can discard or remember for a
period of time after session tear down.

Chris.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: 16 April 2004 08:22
>To: [email-masked]; [email-masked]
>Subject: RE: [Simple] MSRP: DSN lifetime open issue
>
>This is a session mode instant messaging, therefore I would think that
>participants would not care about any DSNs after the session has been
torn
>down. If they want the DSN, then they need to wait before tearing down
the
>session.
>
>In page mode, you would need to allow the DSN to come days later. But
that
>is not the issue here.
>
>I guess I'm suggesting that all outstanding DSNs are discarded. I don't
>think that the penalty that the relay has to try to send the DSN anyway
is
>such a huge problem. If it is, then we probably need to send a MSRP
level
>BYE request that traverses relays.
>
>
>/Hisham
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On Behalf
Of
>> ext Ben Campbell
>> Sent: 15.April.2004 18:31
>> To: Simple WG
>> Subject: [Simple] MSRP: DSN lifetime open issue
>>
>>
>> One open issue concerning MSRP usage of DSN that I would like
>> to close
>> on is, what happens to DSNs after a session is torn down?
>>
>> Example:
>>
>> A          R           B
>> SEND------->
>> <---------OK
>>             SEND----X
>> <---session teardown--->
>> <-----REPORT
>>
>>
>> In this example, A sends a message to B via relay R. The
>> A-->R hop works
>> fine. The R->B hop failes, due to a tcp error. For the sake
>> of argument,
>> consider this to be a worst case TCP error where the TCP stack has to
>> work through the entire retransmission sequence before it
>> gives up, that
>> is, a non-trivial amount of time passes.
>>
>> A and B tear down the session. But since R is not session
>> stateful, it
>> does not know about this.
>>
>> So, the question becomes, what happens to outstanding DSN after a
>> session is closed? Do they just get dropped? (This is not as
>> simple as
>> it sounds, since if a relay is not aware of the session
>> closure, it will
>> still try to send the DSN, wasting resources.)
>>
>> Or, do we want to be able to deliver DSN outside of the scope of the
>> session in which it was generated?
>>
>> I have had several offline discussions with people, and have gotten
>> opinions that range from allowing DSN to be sent days later,
>> to assuming
>> that all outstanding DSN just get discarded.
>>
>> Thoughts?
>>
>> _______________________________________________
>> Simple mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/simple
>>
>
>_______________________________________________
>Simple mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/simple

This message has been scanned for viruses by MailControl - www.mailcontrol.com

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 16 Apr 2004 10:00:14 -0500

One further complication on the "remember for a period of time approach" 
is the fact that the client may close its TCP connection. I expect 
relays will generally not be able to re-open the connections back 
towards the client. (The main point of relays is NAT/FW traversal.)

---

From: Ben Campbell <[email-masked]>
Date: Fri, 16 Apr 2004 10:00:14 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Apr 2004 09:12:53 -0400

I think I agree that DSNs are only needed for the duration of the 
session, given a suitable definition of the session. But I don't think 
the session can be equated with the TCP connection. That connection may 
indeed need to be reestablished after some kind of glitch, such as one 
server falling over and being replaced by a redundant backup.

I think the duration of the session has to be tied to signaling - the 
offer/answer exchange. But that makes life difficult for the relays, 
that aren't parties in that exchange.

But before considering relays, lets consider a simpler case and see what 
issues there are:

Assume we have established a dialog and MSRP session between A & B. 
Then, perhaps as a result of a 3pcc transfer, A receives a reinvite that 
retargets the MSRP media stream to C. As a result, the old TCP 
connection between A&B will be dropped and a new one between A&C will be 
established.

The signaling that accomplishes this won't necessarily be synchronized 
with the media. For instance, an MSRP SEND message from A to B 
(requiring a DSN) may overlap with the sending of an offer from B to A 
to move the stream to C.

We need rules for managing the transition that ensure that the DSN from 
B to A is delivered while the connection is still up and being processed 
by A.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Apr 2004 09:12:53 -0400

Paul