Subject: [Simple] MSRP comments - request/response handling and retrying

From: Aki Niemi <[email-masked]>
Date: Thu, 16 Oct 2003 19:02:29 +0300

Hi,

In the draft, if a SEND times out, the MSRP client is supposed to handle 
this as if a 5xx was received. I.e., it will resend the message a few 
times and then quit the session. In case the other endpoint is in the 
midst of sending a large message, a response may take  longer than the 
request time out value. This will result in a number of duplicate 
messages received. There should be a better way to handle this. Why 
resend in the first place, especially if the connection is active?

Also, what is the motivation for making retransmissions with a different 
TR-ID? Doesn't this go agains the idea of retrying the request?

Regards,
Aki

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

---

From: [email-masked]
Date: Mon, 20 Oct 2003 21:16:24 +0300

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, October 20, 2003 9:11 PM
> To: Ben Campbell
> Cc: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);
> [email-masked]
> Subject: Re: [Simple] MSRP comments - request/response handling and
> retrying
> 
> 
> 
> 
> Ben Campbell wrote:
> > 
> >>> Having a response delayed by a long request in the recipricol 
> >>> direction is a problem I don't think we have considered. 
> I welcome 
> >>> input as to whether we think this is a real issue, and if 
> so, how to 
> >>> deal with it.
> >>
> >> I thought we agreed that large messages should be sent using a 
> >> separate session. Or we change that decision? If not, I 
> cannot recall 
> >> if there was a threshold that classifies as message as large.
> > 
> > You are correct, we have text encouraging this behavior. Since you 
> > reminded me of this, and no one else jumped in to say that 
> this is a big 
> > problem, I am going to assume for now that it is not. If 
> anyone feels 
> > otherwise, please jump in asap.
> 
> I'm not sure if that solves the problem. It just moves it to the 
> separate session. I guess it goes away if we assume that each 
> and every 
> large message should get its very own session, but that doesn't sound 
> like a wonderful solution.
> 
> Perhaps a session intended for large messages should not be used to 
> initiate messages (large or small) in the reverse direction. 
> So, I can 
> create a special stream to send files to you, and pour several files 
> thru it. But if you have files to send to me then you should set up a 
> separate stream.
> 
> That of course punts the question of how the two ends agree on the 
> intended use of a stream. Just because I establish the stream 
> with the 
> intent of sending large messages to you, that doesn't mean you know 
> that. If you don't you might start sending small messages to 
> me over it.
> 
> Maybe we need some sort of purpose attribute, or a maximum size 
> attribute, that can be specified/negotiated during session 
> establishment. One answer might be to use a=sendonly to indicate a 
> stream that should only be used in one direction. On such a 
> stream only 
> responses would be permitted in the reverse direction.

Yes, I was already thinking of this type of solution after reading your third paragraph above :) I don't think there is a need for max size attribute if we have a direction attribute as you suggest.

/Hisham

> 	Paul

---

From: [email-masked]
Date: Mon, 20 Oct 2003 21:16:24 +0300

/Hisham

---

From: [email-masked]
Date: Mon, 20 Oct 2003 20:29:40 +0300

> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: Friday, October 17, 2003 8:44 PM
> To: Niemi Aki (NMP/Helsinki)
> Cc: [email-masked]
> Based on recent discussions, I think we may need to rethink this. The 
> point to resending was _not_ to build a reliability mechanism 
> on top of 
> TCP. We really wanted a mechanism to simply warn the user if we could 
> not be sure the opposite endpoint had actually processed the 
> message. I 
> think we should either remove the text encouraging re-submission, or 
> change it to re-use the same TR-ID, and add text to describe what the 
> peer should do if it sees duplicate TR-IDs.

I would hate to resend a 5gb message. I think there should be a timer for the response, without retransmissions. If the timer fires, then you have to assume that something went wrong in delivering the message. Retransmission won't help.

> direction 
> is a problem I don't think we have considered. I welcome input as to 
> whether we think this is a real issue, and if so, how to deal with it.

I thought we agreed that large messages should be sent using a separate session. Or we change that decision? If not, I cannot recall if there was a threshold that classifies as message as large.

/Hisham

> Aki Niemi wrote:

---

From: [email-masked]
Date: Mon, 20 Oct 2003 21:20:45 +0300

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext [email-masked]
> Sent: Monday, October 20, 2003 9:16 PM
> To: [email-masked]; [email-masked]
> Cc: Niemi Aki (NMP/Helsinki); [email-masked]
> Subject: RE: [Simple] MSRP comments - request/response handling and
> retrying
> 
> 
> 
> 
> Yes, I was already thinking of this type of solution after 
> reading your third paragraph above :) I don't think there is 
> a need for max size attribute if we have a direction 
> attribute as you suggest.

Of course, I don't mean the direction attribute we have now (passive vs. active), but the sendonly.

---

From: [email-masked]
Date: Mon, 20 Oct 2003 21:20:45 +0300

---

From: [email-masked]
Date: Tue, 21 Oct 2003 14:01:29 +0300

> From: Pekka Pessi [mailto:[email-masked]]
> Sent: Tuesday, October 21, 2003 11:27 AM
> Cc: ext Paul Kyzivat; Ben Campbell; Khartabil Hisham 
> (NMP-MSW/Helsinki);
> [email-masked]
> Hi,,
> Aki Niemi <[email-masked]> writes:
> >I think the way round this problem could be that a) we get rid of
> >retransmissions, and b) base the request timeout on both 
> connection activity
> >and a timer. If a request was sent, and the connection stays 
> inactive for
> >the timer to fire, only then would the client assume the 
> session has failed,
> >and proceed with tear down.
> 
> I think we have a problem here because of relays. Even if you 
> have sent
> your message completely and the relay has received it via TCP, it
> does not mean that the whole message has been relayed, even 
> if we assume
> cut-through relaying. Two relays make it worse: there is 3 TCP send
> buffers and receive buffer between sender and recipient.

Yes, the sender might have a fast uplink and the receiver might have a slow downlink, so relying on a timer is not enough (so my earlier suggestion is not sufficient on its own).

> 
> If we add timer, we also need some kind of keepalive messages that can
> be sent while receiving a large message. 100 Continue?

Not a bad idea. But the timer should be standardised so that the receiver can send the 100 responses before the sender times out.

/Hisham

> 				Pekka

---

From: [email-masked]
Date: Tue, 21 Oct 2003 14:01:29 +0300

/Hisham