Subject: Re: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards clos ure on HoL blocking issue)

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 01 May 2003 04:52:24 -0400

Paul Kyzivat wrote:
> 
> 
> Adam Roach wrote:
> 
>> Ben Campbell writes:
>>
>>
>>> Jonathan suggested we should handle flow control by simply dropping
>>> messages. This is not as heinous as it first sounds, since MSRP does
>>> have e2e acknowledgement of message delivery.
>>
>>
>>
>> The prospect of designing yet another protocol that needs to
>> retransmit requests over a *reliable* transport layer if
>> no response is received makes me more than a little queasy.
> 
> 
> You beat me to it - my stomach has been bothering me for awhile too.
> 
> I'm trying to remember why we put the end-to-end acks in. I'm quite sure 
> it wasn't so we could drop messages with the expectation that the sender 
> would retry them. I think maybe it was so the sender can detect when the 
> other end fails.

Acknowledgement of message receipt is a basic requirement from rfc2779.

I also recall it was to deal with failures at relays too.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 01 May 2003 09:03:03 -0400

> I also recall it was to deal with failures at relays too.

There is, however, a difference in degree between rare failures induced 
by relays crashing and congestion/flow control dropping, which would 
occur at a much higher rate if there's a heterogeneous chain. Plus, 
using dropping to regulate flows is a dicey mechanism, since you can 
easily get into congestion collapse, spending all your time and network 
resources on dropping things. Thus, you have to have a back-off 
mechanism, RTO estimation, slow start - and, congratulations, you have 
re-invented TCP at the MSRP layer.

Thus, I'm all for delivery confirmation, but in the spirit of email 
delivery confirmation, not TCP.