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

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

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: Friday, October 17, 2003 8:44 PM
> To: Niemi Aki (NMP/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] MSRP comments - request/response handling and
> retrying
> 
> 
> 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.

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

/Hisham

> 
> Aki Niemi wrote:
> 
> > 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
> 
> 
> 
> _______________________________________________
> 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: Mon, 20 Oct 2003 12:37:37 -0500

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 20 Oct 2003 12:37:37 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Oct 2003 14:10:59 -0400

Ben Campbell wrote:
>>> 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.
> 

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.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Oct 2003 14:10:59 -0400

Paul

---

From: Aki Niemi <[email-masked]>
Date: Tue, 21 Oct 2003 10:43:23 +0300

On 20.10.2003 20:29, ext [email-masked]:
> 
>> -----Original Message----- From: ext Ben Campbell
>> [mailto:[email-masked]] Sent: Friday, October 17, 2003
>> 8:44 PM To: Niemi Aki (NMP/Helsinki) Cc: [email-masked] Subject:
>> Re: [Simple] MSRP comments - request/response handling and retrying
>> 
>> 
>> 
>> 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.

I agree that retransmissions should go. I can't think of a scenario 
where a message would be lost over reliable transports, so that 
retransmitting it would ever help.

But just having the request time out should probably not immediately 
result in session tear down. The MSRP client should at least wait as 
long as the downstream connection is active. The missing response could 
always be pipelined in that stream behind some other request/response.

Regards,
Aki

>> input as to whether we think this is a real issue, and if so, how
>> to deal with it.
> 
>>>  messages received. There should be a better way to handle this.
>>> Why resend in the first place, especially if the connection is
>>> active?
>>> 
>>> Regards, Aki
>>> _______________________________________________ Simple mailing
>>> list [email-masked] 
>> _______________________________________________ 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 10:43:23 +0300

Regards,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Tue, 21 Oct 2003 10:54:05 +0300

> responses would be permitted in the reverse direction.

This sounds like a good solution.

There is still one thing though, what is considered a large message? I 
don't believe we can define a threshold, so a sendrecv stream could 
still end up carrying a sizeable message, and the problem would remain.

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.

Regards,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Tue, 21 Oct 2003 10:54:05 +0300

Regards,
Aki

---

From: Pekka Pessi <[email-masked]>
Date: Tue, 21 Oct 2003 11:27:11 +0300

Hi,,

Aki Niemi <[email-masked]> writes:
>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.

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

				Pekka

---

From: Pekka Pessi <[email-masked]>
Date: Tue, 21 Oct 2003 11:27:11 +0300

Hi,,

				Pekka