Subject: [Simple] MSRP: Administrative shutdown of relays

From: Ben Campbell <[email-masked]>
Date: Wed, 08 Oct 2003 15:43:45 -0500

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

---

From: [email-masked]
Date: Thu, 9 Oct 2003 16:13:01 +0300

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

---

From: [email-masked]
Date: Thu, 9 Oct 2003 16:13:01 +0300

I vote for option 2.

/Hisham

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 9 Oct 2003 14:25:58 +0100

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.

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

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 9 Oct 2003 14:25:58 +0100

Chris.

---

From: [email-masked]
Date: Thu, 9 Oct 2003 16:38:56 +0300

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

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

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 9 Oct 2003 15:54:57 +0100

Both solutions seem OK - It's just a matter of weighing up the argument
for simplicity vs End user experience.  I think I am leaning towards
user experience.

Chris.

>Sent: 09 October 2003 14:39
>To: Chris Boulton; [email-masked]; [email-masked]
>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.
>

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 9 Oct 2003 15:54:57 +0100

Chris.

so,
can

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 10 Oct 2003 15:39:26 +0100

<<See comments>>

>From: Ben Campbell [mailto:[email-masked]]
>Sent: 10 October 2003 15:36
>To: Paul Kyzivat
>Cc: [email-masked]; Chris Boulton; [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.
>
>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?

[Chris Boulton] Not that I can think of - This should be enough
information for a client to realize that this particular instance is
un-available and I should try another relay.
 
>
>
>
>
>
>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:
>>
>>> 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.
>>>
>>>>>> 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:
>>>>
>>>>>> 2) Just close all TCP connections and let the endpoints
>>>>>
>>>>>
>>>> deal with it.
>>>>

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 10 Oct 2003 15:39:26 +0100

<<See comments>>

Rather,

think
relay
A
session,
been
way

---

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

> Sent: Friday, October 10, 2003 5:36 PM
> To: Paul Kyzivat
> Cc: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];
> [email-masked]

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, 
> > 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 
> > applications will probably want to attempt renegotiation of 
> the session, 
> > via a reINVITE.
> > 
> > there is of course the question of messages already sent: 
> have they been 
> > If the connection is just torn down (option 2) then A and B 
> have no way

---

From: [email-masked]
Date: Sun, 12 Oct 2003 14:28:12 +0300

> Sent: Friday, October 10, 2003 11:47 PM
> To: Paul Kyzivat
> > Ben Campbell wrote:
> >> 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.
> > 
> > 
> > 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.
> 
> 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.
> 
> > 
> > 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.
> 
> 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?

If you don't wait the full idle timeout period, then I don't see the point in waiting a couple of mins before shutting down. It is better to just shut down immediately then.

As I said earlier, relay shuts down after the full timeout period, or until it know it has sent 4xx (or 5xx) responses to SEND requests sent by all the participants in all session. Whichever is reached first. In this way, you guarantee that either the clients have been notified of such shutdown on that the clients have timed out themselves anyway.

/Hisham

---

From: [email-masked]
Date: Thu, 16 Oct 2003 13:09:34 +0300

> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, October 14, 2003 12:18 AM
> To: Ben Campbell
> > I did not say it was good. I said I think we can live with 
> it. That is 
> > not the same thing.
> > 
> > It seems to me we have 4 choices:
> > 
> > 1) Live with the potential for duplicate deliveries when a logical 
> > conversation transitions from one session to another in a 
> short time 
> > period. Note that this can happen without relays being 
> involved at all.
> > 
> > 2) Require any hosting device that wishes to end a session 
> wait either 
> > until connected devices send a request, so that we can send 
> a response 
> > indicating that we are shutting down, or until an 
> inactivity timeout 
> > occurs.
> > 
> > 3) Allow relays to originate a message saying the session 
> is going down.
> > 
> > 4) Create a cross-session duplicate supression mechanism.
> > 
> > 3) and 4) seem awfully heavy-weight for the value they 
> create. 2) either 
> > puts a big burden on hosting device shutdown time, or 
> requires us to 
> > significantly shorten the timer value--which, as has been 
> discussed at 
> > length on this list, is also heavy-weight.
> > 
> > Of these choices, I prefer option 1.
> 
> I think you managed to summarize the choices quite well.
> 
> I prefer either 2, or 4. Of those, 2 is the simpler, and I 
> would be ok 
> with reducing the timer value to make it responsive enough. 
> OTOH, 4 also 
> works in the case of a server crashing ungracefully, which 2 
> won't cover.
> 
> I think 1 is a non-starter. We are all geeks, and can be tolerant of 
> such misbehavior if we understand why it is happening. Others 
> will not 
> be so tolerant. They especially won't be tolerant if the 
> message happens 
> to be their 5gb movie.
> 
> Now that I think about it, the 5gb message may be a reason to 
> prefer 4. 
> (Or 3): I don't think 2 works for that case.

Is the relay required to receive the whole message before it can respond to it with a 5xx error response? To ask the same question froma client point of view: is the client expecting to send the whole message out before it receives a response? If the answer to both is no, then option 2 may still work.

The problem remains that the relay has started forwarding the message, but it is being shutdown midway. In this case, we can either mandate the the relay must not be sutdown unless it has finished what it started, or the receiving end needs to tolerate receing the first part of a message again.

Regards,
Hisham

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 16 Oct 2003 11:43:09 +0100

>Sent: 16 October 2003 11:10
>To: [email-masked]; [email-masked]
>Cc: Chris Boulton; [email-masked]
>Is the relay required to receive the whole message before it can
respond to
>it with a 5xx error response? To ask the same question froma client
point
>of view: is the client expecting to send the whole message out before
it
>receives a response? If the answer to both is no, then option 2 may
still
>work.
>
>The problem remains that the relay has started forwarding the message,
but
>it is being shutdown midway. In this case, we can either mandate the
the
>relay must not be sutdown unless it has finished what it started, or
the
>receiving end needs to tolerate receing the first part of a message
again.
>Hisham

[Chris Boulton] As this is an administrative shutdown, should we not
just wait until the current message has been forwarded (but include a
generous timeout for ridiculous size transfer).  If this timeout is then
exceeded, you just dump the connections and the client has to resend
using an alternative TR-ID.

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 16 Oct 2003 11:43:09 +0100

respond to
point
it
still
but
the
the
again.