Subject: [Simple] MSRP: DSN lifetime open issue

From: Ben Campbell <[email-masked]>
Date: Thu, 15 Apr 2004 10:30:51 -0500

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

---

From: [email-masked]
Date: Fri, 16 Apr 2004 10:22:13 +0300

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

---

From: [email-masked]
Date: Fri, 16 Apr 2004 10:22:13 +0300

/Hisham

---

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.

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

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

---

From: [email-masked]
Date: Mon, 19 Apr 2004 16:50:24 +0300

There are 2 cases here:

1. The SEND arrives at B before the transfer is complete and the TCP connection is dropped
2. The SEND does not arrive at B before the transfer is complete and the TCP connection is dropped.

2 is easier to solve, A would probably get a negative DSN or no response at all (if no relays)

1 might be solved by mandating that B must not drop the connection unless it has sent all pending DSNs.

/Hisham

> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 19.April.2004 16:13
> To: Ben Campbell
> Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki);
> [email-masked]
> Subject: Re: [Simple] MSRP: DSN lifetime open issue
> 
> 
> 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
> 
> Ben Campbell wrote:
> > 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.)
> > 
> > Chris Boulton wrote:
> > 
> >>>> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> >>>
> >>
> >> Of
> >>
> >>>> ext Ben Campbell