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

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

Hi Ben,

Inline.

 > -----Original Message-----
 > 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.
 > > 
 > > 
 > > 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?
 > 
 > 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
 > >>
 > > 
 > > 
 > > _______________________________________________
 > > 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: Fri, 17 Oct 2003 10:14:06 -0500

[email-masked] wrote:

[...]

>       failed, and initiate tear-down via the signaling protocol.

Sure, it says the connection should be torn down. It does not say 
anything at all about whether a client should automatically attempt to 
create a new session or not. I don't think we should specify that sort 
of behavior one way or another. It does not seem to affect 
interoperability in any way.

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

By auto-resume, I mean the idea that an endpoint might decide to go 
through the entire SDP handshake of creating a _new_ session (that is 
only connected with the old session in the user's head), and might 
attempt to resubmit any IMs that it had sent on the prior session for 
which it had not gotten a successful response. These would be new 
transactions, only coincidentally related to the failed transactions.

Again, I think some implementors might choose to do this, but we should 
no more recommend or forbid this than we should tell implementers what 
color to make their buttons.

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

Yes, this is true. THe discussion has not been so much about retrying a 
message on a particular session, as attempting to start a new session 
when the client thinks an old session has gone bad.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Oct 2003 10:14:06 -0500

[...]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Oct 2003 11:55:29 -0400

Ben Campbell wrote:
>> 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:
>>
...
> color to make their buttons.

I don't think we should recommend or forbid this. But I think it may be 
necessary to say something about how you should do it, if you want to, 
so that we get proper interoperation.

This is very closely related to the process of transferring a call with 
an MSRP session. The transfer may appear to one endpoint as either an 
in-dialog refer, an invite/replaces, or a reinvite. In any of these 
cases a new MSRP session will be established that will eventually 
replace the old one. But there is some ambiguity about how to handle 
messages during the transfer. This has largely been ignored for voice, 
where arguably it only results in a small glitch that doesn't have 
significant consequences. But in the case of MSRP it can result in the 
duplication, loss, or misdirection of whole messages, which is more 
significant than a glitch. This is probably the wrong document to 
address this - it may require a document of its own. But getting it 
right may end up needing help from MSRP.

Related point: Aki or somebody previously pointed out the passage above 
about retrying 5xx responses. If a relay has gone down, or is trying to 
shut down, this retrying behavior is counterproductive. We ought to ban 
retries at least after receiving the code indicating the relay wants to 
shut down.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Oct 2003 11:55:29 -0400

...

	Paul