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

From: [email-masked]
Date: Mon, 20 Oct 2003 13:25:25 +0300

> -----Original Message-----
 > From: ext Ben Campbell [mailto:[email-masked]]
 > Sent: 17 October, 2003 18:14
 > To: Niemi Aki (NMP/Helsinki)
 > Cc: [email-masked]; [email-masked]; [email-masked]
 > Subject: MSRP: resuming sessions (was Re: [Simple] Chair 
 > call for group
 > opinion (was MSRP: Administrative shutdown of relays))
 > 
 > 
 > [email-masked] 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:
 > > 
 > > 	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.
 > 
 > 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.

OK, then I misinterpreted you before. I thought by auto-resume, the MSRP client would try to resume the *MSRP* session, meaning something like establish a new TCP connection, do a VISIT, etc. Maybe some clarification to the term "session" is needed here?

One thing related to this though, in case an MSRP peer wants to establish a new MSRP connection for e.g. filetransfer, should it assume the "direction" properties of the existing MSRP session, or should the endpoints do a full handshake on it?

My proposal (which would require some text in MSRP) would be that the directional proerties of the original MSRP connection are reused. I would expect the circumstances in the network to remain constant, so that the direction of the new MSRP session would likely turn out the same as the original one.

Regards,
Aki

 > 
 > 
 > >  
 > >  > > 
 > >  > > 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.
 > 
 > 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.
 > 
 > 
 > 
 > >  
 > >  > >> 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.
 > 
 > 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.
 > 
 > > 
 > > 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: Aki Niemi <[email-masked]>
Date: Tue, 21 Oct 2003 11:01:02 +0300

> From: [email-masked] [mailto:[email-masked]]On
  > Behalf Of
  > ext Ben Campbell
  > Sent: 20 October, 2003 20:35
  > Subject: Re: MSRP: resuming sessions (was Re: [Simple] Chair call for
  > group opinion (was MSRP: Administrative shutdown of relays))
  >
  >
  > > OK, then I misinterpreted you before. I thought by
  > auto-resume, the MSRP client would try to resume the *MSRP*
  > session, meaning something like establish a new TCP
  > connection, do a VISIT, etc. Maybe some clarification to the
  > term "session" is needed here?
  > >
  > > One thing related to this though, in case an MSRP peer
  > wants to establish a new MSRP connection for e.g.
  > filetransfer, should it assume the "direction" properties of
  > the existing MSRP session, or should the endpoints do a full
  > handshake on it?
  > >
  > > My proposal (which would require some text in MSRP) would
  > be that the directional proerties of the original MSRP
  > connection are reused. I would expect the circumstances in
  > the network to remain constant, so that the direction of the
  > new MSRP session would likely turn out the same as the original one.
  > >
  >
  > Why do we need to special case this? I don't think the added
  > efficiency
  > is enough to justify the special case.

Well, because it *is* a special case. I think it's quite reasonable to 
expect that an endpoint having said "both" the first time around, failed 
to be the host, and consequently forced to visit, would not reinvite 
using direction:both, but direction:active instead.

Having said that though, this is possible to do as the text stands now. 
So no additional specification needed, except some informative note, if 
anything.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Tue, 21 Oct 2003 11:01:02 +0300

Cheers,
Aki