Subject: [Simple] Chair call for group opinion (was MSRP: Administrative shutdown of relays)

From: Robert Sparks <[email-masked]>
Date: Mon, 13 Oct 2003 18:31:19 -0500

If you have not been  reading the Administrative shutdown of relays
thread, the following provides a summary of the possible paths the
thread has explored:

In interests of progress _before_ Minnesota, I would like to get input
from people other than the 3 primary participants in the tread as to
what they believe is important for us to work on.

So, I am calling an electronic hum. Respond to list or privately to
me if you prefer. The questions called are:

One: Do you believe it is important for the document to discuss
    administrative shutdown of relays.

Two: (answer only if you answer Yes to question One). 
    How much scope creep are we willing to take on?
    The options below are listed in increasing scope creep order.
    Please respond with which option you would like to see pursued.

Please respond to this call no later than Wed 10/15.

RjS

-----Forwarded Message-----
> From: Ben Campbell <[email-masked]>
>
> 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.
This potential can be bounded by shorter than inactivity timeout delays
(specifically watiting for transactions already in progress to
complete).

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

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

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 14 Oct 2003 08:33:52 +0100

<<comments in-line>>

>-----Original Message-----
>From: Robert Sparks [mailto:[email-masked]]
>Sent: 14 October 2003 00:31
>To: [email-masked]
>Subject: [Simple] Chair call for group opinion (was MSRP:
Administrative
>shutdown of relays)

[Chris Boulton] Yes.

>    Please respond with which option you would like to see pursued.

[Chris Boulton] Option 2 is my preferred.

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 14 Oct 2003 08:33:52 +0100

<<comments in-line>>

Administrative

[Chris Boulton] Yes.

---

From: [email-masked]
Date: Wed, 15 Oct 2003 16:48:14 +0300

Hi,

Inline.

 > From: ext Robert Sparks [mailto:[email-masked]]
 > Sent: 14 October, 2003 02:31
 > To: [email-masked]

No. And I'm going to have to ask a couple of stupid questions, too.

1) Since duplicate delivery is the reason a relay would need to care about shutting down gracefully in the first place, what are the reasons a SEND would time out; who drops it; and why would an MSRP endpoint retransmit if that happens?

2) Isn't this identical to a proxy server forwarding a MESSAGE (via TCP) and then shutting down?

I thought this is what we wanted to avoid with MSRP. If a relay also processes the SEND (i.e., receives it in entirety before forwarding it along on another connection), this bases a big burden on the relay when the SEND contains a 5GB movie.

Why can't a relay simply peek at the first few bytes of message, see if it is not a BIND or VISIT, and forward it byte-by-byte over to the associated TCP connection. If there is trouble upstream, simply mirror that trouble downstream.

This way, there are never messages in-transit over relay(s) (with the exception of a VISIT, which is always processed by a relay, but can also be forwarded to another target).

If the above simply isn't feasible, then my answer would probably be yes, but I'd have to think between option 1 and 3. 

Regards,
Aki

---

From: [email-masked]
Date: Fri, 17 Oct 2003 12:24:53 +0300

Hi Paul,

Paul wrote:
 > > Right. I guess the difference in MSRP is that a TR-ID is 
 > only unique 
 > > within a connection. Does it need to be? Could option#4 
 > simply be to 
 > > make TR-ID globally unique?
 > 
 > Perhaps. But then I don't know how an application would 
 > decide when it 
 > could forget a TR-ID.

I'm not sure if there needs to be anything additional to how it currently stands. It is currently scoped within a given session, with SHOULD strength global uniqueness. My interpretation is that the application needs to remember all TR-IDs used in a given session, up until a response to those requests is received.

Here, I understood "session" to mean the session initiated using SIP. This would normally be equal to the MSRP session (or connection), but of course if clients automatically reconnect due to failure, "session" would span over multiple MSRP connections.h

Regards,
Aki

---

From: [email-masked]
Date: Fri, 17 Oct 2003 12:24:53 +0300

Hi Paul,

Regards,
Aki

---

From: [email-masked]
Date: Fri, 17 Oct 2003 12:47:19 +0300

Hi Ben,

Inline.

 > From: ext Ben Campbell [mailto:[email-masked]]

[snip]

 > >> If the relay is shut down without advance notice of the 
 > application,
 > >>  there is certainly a chance that a message sent by the 
 > app will not
 > >>  arrive. If the application wants to survive the relay 
 > shutdown, then
 > >> it will need to somehow detect the situation, establish a new
 > >> connection, and retry the send.
 > > 
 > > 
 > > IMO, this behavior is not specified in the spec. Request 
 > timeouts are 
 > > interpreted as 5xx, which means the client will resend a 
 > few times and 
 > > then give up.
 > 
 > It is not specified--but it is likely that some implementations will 
 > attempt to resume a session. Other implementations might 
 > simply tell the 
 > user that the session was ended, and the last message(s) may 
 > or may not 
 > have been delivered.

Is this acceptable? A lot of the discussion so far has made the assumption that an MSRP client would reconnect and resend if there is a timeout, a 5xx, or the connection to the relay closes. That isn't the defined behavior, it actually goes against the defined behavior.

Bullet 5, Ch 7.4.3:

	If the endpoint receives 5xx responses more than some threshold
      number of times in a row, it SHOULD assume the session has
      failed, and initiate tear-down via the signaling protocol.
 
 > > 
 > > We need text describing how and when an MSRP session 
 > transitions to a 
 > > new connection (or alternatively, someone can point me to 
 > the existing 
 > > text ;))
 > > 
 > 
 > Why? It is not our lot to define user experience, only to define 
 > protocol behavior. Different implementers may have entirely 
 > different 
 > requirements here. We assume that some implementers will attempt to 
 > auto-resume sessions.

What do you mean by auto-resume? I am not talking about user experience here. I believe it is protocol behavior to describe what happens when a SEND times out, or a 5xx is received. Currently the behavior is that a client MAY retransmit, then quits the session. If the client may also reconnect and resend, then that needs to be included as well.
 
 > >> Relays shutting down gracefully, and timeouts on messages 
 > are simply
 > >>  ways for the application to learn what it needs to 
 > achieve its ends.
 > >>  Without some help, the application can't do this.
 > > 
 > > 
 > > Naturally, some help is also provided by the reliable 
 > connection the 
 > > MSRP runs on top of.
 > >
 > 
 > Certainly this is true for some cases. But it cannot guarantee to me 
 > that in the case where I send a message and get no response, 
 > that I know 
 > that the opposite peer did not receive it.

True. But it can give you a certain amount of more confidence that if a SEND times out, gets a 5xx, a retransmission will likely not give a better result, as opposed to if we were running MSRP over an unreliable transport.

Regards,
Aki
 
 > >>> 2) Isn't this identical to a proxy server forwarding a 
 > MESSAGE (via
 > >>> TCP) and then shutting down?
 > >>
 > >>
 > >> SIP errs on the side of sending duplicates, and depends on the
 > >> recipient to recognize and discard them. Doing the same in MSRP is
 > >> the 4th choice in the vote.
 > > 
 > > 
 > That is what I had in mind _if_ we chose to pursue option 4. 
 > But it is 
 > more complex than just that--we would have to worry about how long a 
 > receivor had to remember what TR-IDs it had seen in the past.
 > 
 > > 
 > >>> I thought this is what we wanted to avoid with MSRP. If a relay
 > >>> also processes the SEND (i.e., receives it in entirety before
 > >>> forwarding it along on another connection), this bases a 
 > big burden
 > >>> on the relay when the SEND contains a 5GB movie.
 > >>
 > >>
 > >> A relay clearly does "process" a SEND, but I don't think 
 > we have made
 > >>  any require that it receive the whole thing before 
 > forwarding it on.
 > >> If that is what you mean we wanted to avoid, then I think we have.
 > >>
 > >>> Why can't a relay simply peek at the first few bytes of message,
 > >>> see if it is not a BIND or VISIT, and forward it 
 > byte-by-byte over
 > >>> to the associated TCP connection. If there is trouble upstream,
 > >>> simply mirror that trouble downstream.
 > >>
 > >>
 > >> It can. It can also know that it is in the midst of forwarding a 
 > >> message. If it wants to shutdown before transmitting the 
 > last byte of
 > >>  the message, it can send an error response indicating 
 > this is what
 > >> happened.
 > > 
 > > 
 > > Except that an MSRP client probably isn't expecting a 
 > response to a 
 > > request it is still in the process of sending?
 > 
 > We already have the ability for the peer endpoint to 
 > interrupt a message 
 > with an early response. It does clobber framing for the 
 > connection, and 
 > therefore requires the peer to also close the connection.

I didn't see this spelled out anywhere in the draft.

Regards,
Aki

 > > 
 > >>> This way, there are never messages in-transit over relay(s) (with
 > >>> the exception of a VISIT, which is always processed by a 
 > relay, but
 > >>> can also be forwarded to another target).
 > >>
 > >>
 > >> I don't see why this means there aren't messages in-transit.
 > > 
 > > 
 > > You're right. The problem does not go away. Even though 
 > there might be 
 > > fewer states the system could be in, the relay could still 
 > shut down 
 > > when the request is pending - and the problem would remain.
 > > 
 > > Basically, the reason I'm raising these questions is that 
 > at least for 
 > > the non-relay case, I would like things to be as simple as 
 > in IRC. That 
 > > is, to send a message, you write it to a buffer and flush 
 > it. Granted, 
 > > the presence of relays will make things a bit more 
 > complicated, but 
 > > still we should avoid adding complexity unless it's 
 > absolutely necessary.
 > > 
 > > Regards,
 > > Aki
 > > 
 > >> Paul
 > >>
 > > 
 > >