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

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

> -----Original Message-----
> 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:
> > 
> >> 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
> > 
> 
> 

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 19 Apr 2004 09:37:13 -0500

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

That handles _intentional_ dropping of tcp. But it does not handle 
_unexpected_ failures.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 19 Apr 2004 09:37:13 -0500