Subject: RE: [Simple] Overload (was MSRP: Administrative shutdown of relays)

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

> -----Original Message-----
> From: ext Robert Sparks [mailto:[email-masked]]
> Sent: Friday, October 10, 2003 5:46 PM
> To: [email-masked]
> Subject: [Simple] Overload (was MSRP: Administrative shutdown 
> of relays)
> 
> 
> (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? 

Maybe the relay shouldn't have accepted that number of sessions in the first place. Network administrators should know the capacity of their relays and load balance sessions accordingly. If existing session capacity overwhelms a relay, you can blame it on the administrator for the relay crashing :)

Alternatively, I think you suggestion below works (with a minor adjustment)

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

The relay can then reject those BINDs.

/Hisham

> 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
> 
> On Fri, 2003-10-10 at 09:35, Ben Campbell wrote:
> > 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:
> > 
> > > 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
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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