Subject: RE: [Simple] MSRP: Administrative shutdown of relays

From: [email-masked]
Date: Fri, 10 Oct 2003 17:45:21 +0300

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: Friday, October 10, 2003 5:36 PM
> To: Paul Kyzivat
> Cc: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];
> [email-masked]
> Subject: Re: [Simple] MSRP: Administrative shutdown of relays
> 
> 
> I had originally read Hisham's suggestion as having the relay 
> wait for 
> up to a full inactivity timeout between the time it stops 
> allowing SEND 
> and the time it drops the connections. Assuming this timer 
> value is 10 
> (or 12 for Adam :-) ) minutes, this seemed like an excessive burden.

No, I suggested that either the relay waits the full timeout, or until it know it has sent 4xx (or 5xx) response to SEND requests sent by all the participants in all session. Whichever is reached first.

Regards,
Hisham

> 
> But in the case you mention, a full timeout would not be 
> needed. Rather, 
> just waiting a reasonable time to make sure that there are no SEND 
> transactions in play would be sufficient. Is that what you 
> had in mind? 
> If so, I don't have a problem putting in as a SHOULD strength.
> 
> Does anyone have thoughts on an appropriate response code for 
> this? We 
> already have 481 for no session, which seems borderline 
> appropriate. We 
> also have 500 which means "unable to forward SEND request" which is 
> exactly the case but could be a little too generic. Is there a case 
> where a client would handle a 500 different than some 5xx "relay 
> shutting down" response?
> 
> 
> 
> 
> 
> Paul Kyzivat wrote:
> 
> > What Hisham says sounds good to me.
> > 
> > I'm trying to think of a scenario where this makes a 
> difference. I think 
> > I have one:
> > 
> > Suppose there is an MSRP session between A and B, and 
> involving a relay 
> > R1. Some administrator wants to shut down R1. This doesn't 
> mean that A 
> > and B want to stop chatting. When the relay goes down, the chat 
> > applications will probably want to attempt renegotiation of 
> the session, 
> > via a reINVITE.
> > 
> > Assuming they can find a substitute relay, this should work ok. But 
> > there is of course the question of messages already sent: 
> have they been 
> > delivered, or should they be sent again? If they are sent 
> again, the 
> > recipient may see the same message appear twice.
> > 
> > If the connection is just torn down (option 2) then A and B 
> have no way 
> > of knowing whether the message outstanding were received, 
> and so will 
> > have to assume no and retransmit. If option 1 is used, then the 
> > connection will go down smoothly and there will be no 
> question, so no 
> > repeated messages.
> > 
> >     Paul
> > 
> > [email-masked] wrote:
> > 
> >> Does a 400 response for a SEND request terminate the MSRP 
> session? If 
> >> so, then option 1 (or a variant thereof) would be simple enough: A 
> >> Relay refuses all SEND requests, once it has done so for every 
> >> connection, it can assume all sessions are done and shut down.
> >>
> >> Of course option 2 is much SIMPLEr.
> >>
> >> /Hisham
> >>
> >>
> >>> -----Original Message-----
> >>> From: ext Chris Boulton [mailto:[email-masked]]
> >>> Sent: Thursday, October 09, 2003 4:26 PM
> >>> To: Khartabil Hisham (NMP-MSW/Helsinki); 
> [email-masked];
> >>> [email-masked]
> >>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays
> >>>
> >>>
> >>> The only benefit I can see from using option 1 would be that an
> >>> appropriate response/reason phrase to the SEND requests 
> would allow a
> >>> more graceful shutdown of sessions in an endpoint (The 
> host of this
> >>> session is terminating so I must dispose of the MSRP 
> session) BUT I also
> >>> see that option 2 keeps it SIMPLE ;-).
> >>>
> >>> Chris.
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] 
> [mailto:[email-masked]]
> >>>> Sent: 09 October 2003 14:13
> >>>> To: [email-masked]; [email-masked]
> >>>> Subject: RE: [Simple] MSRP: Administrative shutdown of relays
> >>>>
> >>>> I vote for option 2.
> >>>>
> >>>> /Hisham
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: ext Ben Campbell [mailto:[email-masked]]
> >>>>> Sent: Wednesday, October 08, 2003 11:44 PM
> >>>>> To: [email-masked]
> >>>>> Subject: [Simple] MSRP: Administrative shutdown of relays
> >>>>>
> >>>>>
> >>>>> I just realized that we had one more subject brought up in
> >>>>> Vienna where
> >>>>> we decided to "take it to the list". Which of course has not
> >>>>> yet happened.
> >>>>>
> >>>>> The question was brought up that, in the previous version of
> >>>>> MSRP where
> >>>>> we refreshed state with BIND and VISIT, we had an implied
> >>>>> mechanism by
> >>>>> which a relay could shed load for shutdown. That is, is
> >>>>> starts refusing
> >>>>> refreshes until all sessions have expired.
> >>>>>
> >>>>> Since we have moved to a keep-alive approach rather than 
> >>>>
> >>>>
> >>> the refresh
> >>>
> >>>>> approach, this is not as clean. A couple of approaches 
> >>>>
> >>>>
> >>> come to mind:
> >>>
> >>>>> 1) Start refusing _any_ SEND requests, then assume all the
> >>>>> sessions are
> >>>>> gone when the timeout period expires.
> >>>>>
> >>>>> 2) Just close all TCP connections and let the endpoints 
> >>>>
> >>>>
> >>> deal with it.
> >>>
> >>>>> I find myself leaning toward 2, as 1 does not allow the
> >>>>> endpoints to do
> >>>>> anything useful on the session anyway.
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> Ben.
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Simple mailing list
> >>>>> [email-masked]
> >>>>> https://www1.ietf.org/mailman/listinfo/simple
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> Simple mailing list
> >>>> [email-masked]
> >>>> https://www1.ietf.org/mailman/listinfo/simple
> >>>
> >>>
> >>
> >> _______________________________________________
> >> 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: Fri, 10 Oct 2003 10:06:43 -0500

> No, I suggested that either the relay waits the full timeout, or until it know it has sent 4xx (or 5xx) response to SEND requests sent by all the participants in all session. Whichever is reached f…

That is not far from the same thing, since if there was a single idle 
session, it will take up to 1 timeout for each endpoint to send a 
request that the relay could respond to.

But my point was, for Paul's scenario, it is not neccessary to wait for 
idle endpoints to get around to sending a request. You just have to wait 
long enough so that it is very unlikely that any transactions are still 
in play. A small number of minutes should be plenty of time.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Oct 2003 10:06:43 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Oct 2003 16:12:26 -0400

> in play. A small number of minutes should be plenty of time.

Hmm. How does waiting decrease the likelihood that messages are still in 
play? Even though there have been no messages in the last N minutes, one 
could just have been sent.

To be sure there are none, I think you must in general wait for the 
timeout interval if the stream is idle. But if the stream is active, you 
can just start sending the magic error code to every received message 
for awhile, with the understanding that a sending, upon receiving this 
code, will no longer send messages on the stream. Then, after enough 
time has passed for all messages in the pipeline to have been received, 
then stream can be shutdown.

To speed up shutdown of an inactive stream I think either the inactivity 
timeout needs to be reduced, or else there needs to be a special 
graceful close message that can be sent.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Oct 2003 16:12:26 -0400

Paul

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Oct 2003 15:47:14 -0500

Paul Kyzivat wrote:

>> But my point was, for Paul's scenario, it is not neccessary to wait 
>> for idle endpoints to get around to sending a request. You just have 
>> to wait long enough so that it is very unlikely that any transactions 
>> are still in play. A small number of minutes should be plenty of time.
> 
> 

If the goal is to make the relay notifies all endpoints prior to 
shutting down, then yes, you would have to wait for a full inactivity 
timeout period. But that was not the scenario you subscribed. If the 
relay begins sending 500 responses to any message at time T, then it can 
assume that there are no more outstanding transactions at T+N. Where N 
is the _transaction_ timout, rather than the inactivity timeout. (Now, 
we do not actually define the transaction timeout--it is currently 
listed as some "reasonable period of time." Maybe we need to specify 
that, but I am not sure this particular reason is enough to force that 
issue.)

So, at time T+N, the relay can reasonably assume that any transaction 
that was already in progress when it started sending the 500s has either 
completed or timed out. I suppose there could be requests that are still 
sitting in the endpoints TCP send buffer and never get a 500, but that 
would be a pretty small percentages of messages overall.

> graceful close message that can be sent.

I gather that you are looking for a "perfectly" graceful shutdown, that 
guarantees that the endpoint will know for sure that a given message has 
been delivered or not delivered.  I accept that it may be polite 
behavior to minimize messages in "limbo". But nothing in MSRP guarantees 
that a SEND transaction that times out without a response has not 
actually been delivered. We can only guarantee that, if you get a 
successful response back, the message _has_ been delivered.

So I think it is reasonable to suggest that a relay wait a couple of 
minutes after it stops relaying requests before it actually shuts down. 
I don't think it is reasonable to ask it to wait 12 minutes, and I don't 
think that this particular issue provides sufficient motivation to 
reduce the idle timer.

What do others think on this point?

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Oct 2003 15:47:14 -0500