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

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Oct 2003 08:42:35 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Oct 2003 08:42:35 -0400

Paul

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Oct 2003 09:35:33 -0500

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?

Paul Kyzivat 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.
>>
>>> session is terminating so I must dispose of the MSRP session) BUT I also

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Oct 2003 09:35:33 -0500

---

From: Robert Sparks <[email-masked]>
Date: Fri, 10 Oct 2003 09:45:57 -0500

(as not-the-chair):

It occurs to me that we have another scenario that deserves exploration.
What do we have a relay do when it reaches capacity?

Rejecting new binds is obvious, but what do we do when traffic on
existing sessions begins to overwhelm the relay? Beginning to terminate
some of them by 481ing selected SENDs would help, but that would likely
result in an immediate reattempt to BIND (along with a TCP connect).
Do we want to avoid that and have some way to say "Go away and don't
bother me again until x amount of time has passed"?

RjS

---

From: Robert Sparks <[email-masked]>
Date: Fri, 10 Oct 2003 09:45:57 -0500

(as not-the-chair):

RjS

---

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

> bother me again until x amount of time has passed"?

We could add something like a retry-after. But would it be enough to 
have the relay simply stop accepting binds _and_ send some 481s? Maybe 
even stop listening for new TCP connections entirely?

---

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

---

From: Dean Willis <[email-masked]>
Date: Fri, 10 Oct 2003 11:01:58 -0500

> bother me again until x amount of time has passed"?

Remember when I predicted that we were going to end up with an
almost-exact replica of SIP and might as well just use MESSAGE?

Just checking.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 10 Oct 2003 11:01:58 -0500

Just checking.

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Fri, 10 Oct 2003 11:19:15 -0500

I'm not suggesting mimicking SIPs 503/Retry-After - its granularity
is too coarse. 

There are other approaches we could look at (like the way sendmail
quits accepting connections when it gets resource constrained. But,
I would like to know if the working group thinks exploring this
functionality is warranted before diving any deeper into the
mechanism though. 

RjS

---

From: Robert Sparks <[email-masked]>
Date: Fri, 10 Oct 2003 11:19:15 -0500

RjS