Subject: Re: [Simple] TCP connection reuse query

From: Ben Campbell <[email-masked]>
Date: Wed, 2 Mar 2011 08:29:20 -0600

On Feb 28, 2011, at 11:37 PM, Ben Campbell wrote:

> On Feb 28, 2011, at 11:14 PM, Achint Aggarwal wrote:
> 
>> Hi,
>>  
>> RFC 4976 Section 3 says:
>> “For client-to-client communication, the sender of a message typically
>>    opens a new TCP connection (with or without TLS) if one is needed.
>>    Relays reuse existing connections first, but can open new connections
>>    (typically to other relays) to deliver requests such as SEND or
>>    REPORT.”
>>  
>> Consider a scenario where an MSRP client establishes an MSRP session and client’s relay opens a connection with its next hop to route the MSRP packets coming to it from the client.
>> Now if the same client wants to start another session then how can the same relay reuse the same connection opened earlier for this new session??
> 
> The general idea is, If the relay receives a SEND request where the next hop URI in the To-Path field resolves to an address and port to which the relay already has a TCP connection, it sends the forwards the request over that connection.
> 
> Of course, it only works if the next hop is the same for both sessions.

After sending that, it occurred to me that things could be a little more complicated if TLS is used (which it should be). You would also want to make sure that the domain name associated with next hop of the new session matched the TLS cert from that end of the existing connection. The simplest approach would be to only reuse if the domain part of the MSRP URI for the new session matched the one from an existing one. It might be possible to be more aggressive by saying the new domain name from the new URI could match any name from the next hop TLS cert, but that starts to get complicated.

IIRC, neither RFC discusses this in any detail. Does anyone else have thoughts on the topic?

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 2 Mar 2011 15:36:06 +0100

I remember running into other issues as well when building the MSRP Relay a few years ago and we gave up on reusing connections. I remember the critical one was the impossibility to apply different QoS / throttling techniques if multiple sessions are sharing the same TCP connection. If each session uses its own TCP connection is possible to prioritize and shape the traffic very easily depending on the type of sessions (e.g. chat or large file transfer).

Adrian

On Mar 2, 2011, at 3:29 PM, Ben Campbell wrote:

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 2 Mar 2011 08:44:14 -0600

Hi Adrian,

I assume you were applying traffic shaping at the IP or TCP layer, right?  Did your traffic shaping device have awareness of the MSRP session purpose or content?

It seems like a relay could apply policies for uneven mixing of sessions onto a TCP connection. 

Thanks!

Ben.

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 2 Mar 2011 15:45:58 +0100

Yes indeed you could but the load and complexity would be much bigger if you move into the application something that you already have at TCP/IP level.

Adrian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 13 Mar 2011 23:15:57 +0100

2011/3/2 Ben Campbell <[email-masked]>:
> Did your traffic shaping device have awareness of the MSRP session purpose
> or content?

NAT routers with SIP ALG enabled by default are a pain for SIP
protocol as most of them break SIP. And now, do we really want to
promote "MSRP aware" devices?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Sun, 13 Mar 2011 20:45:04 -0500

Don't get me wrong--I was not trying to recommend it. I was just trying to understand the scenario.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 14 Mar 2011 02:50:17 +0100

> Don't get me wrong--I was not trying to recommend it. I was just trying to understand the scenario.

Sure, I just meant that SIP should not rely on SIP-aware routers as
IMHO most of them break the signalling.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>