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

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

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, October 14, 2003 12:18 AM
> To: Ben Campbell
> Cc: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];
> [email-masked]
> Subject: Re: [Simple] MSRP: Administrative shutdown of relays
> 
> 
> 
> 
> Ben Campbell wrote:
> > 
> > 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

> 
> 	Paul
> 
> 
> _______________________________________________
> 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: Thu, 16 Oct 2003 09:41:34 -0500

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

No, it is not. We already allow devices to interrupt a long message by 
sending an early response. That device must, however, also drop the 
connection, as framing is pretty much done for at this point.

But given that Paul has agreed that option 1 does not introduce 
duplicate messages, why are we still considering option 2? Do you 
disagree with Paul's analysis?

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

That is already implied by the ability to interrupt messages.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 16 Oct 2003 09:41:34 -0500