Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection

From: [email-masked]
Date: Thu, 20 Nov 2003 15:57:30 +0100

Hi all,

 Let me give some more facets to the discussion:

 Many times the latency is not just the TCP handshake, but has other contributors as well. In case of IPSec, there is no abundance of TCP connection possibilities, those are limited to at most the number of SAs available. And in order to set up a new SA, the use of an additional protocol (e.g. IKE, or RFC3310) is needed. So it is not only the new TCP setup delay, but also the SA setup delay. In case of TLS the handshake costs quite a few messages too.

 Besides the >64K messages, and general SigComp errors, RFC3486 is the other reason to have SigComp and non-SigComp messages multiplexed (at least in time). Endpoints have the possibility to indicate willingness for receiving SigComp messages on a per transaction basis (for example a CPU-challenged endpoint wants to compress delay-sensitive session setups, but not instant messages). We should not burden that choice with significant additional delay, because that would take away useful functionalites from RFC3486.

 In many protocols (HTTP being one of them), TCP connection close has also application level meanings, thus opening a new connection may cause application level delays as well as a different user experience or protocol behavior.

BR,
Robert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: November 19,2003 22:01
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp 
> messages on
> t he same TCP connection
> 
> 
> Hi,
> 
> If I remember correctly, what has been closed/clarified was that 
> RFC 3320 does not allow multiplexing. 
> 
> However, the issue here is whether or not the multiplexing is needed. 
> Obviously, people already have their own opinions in mind. But until
> recently, there haven't been many technical discussions regarding 
> this issue on ROHC mailing list. So, I'm not sure what do you mean
> by "we have already closed the issue several times"? Or did I miss
> anything?
> 
> Either way, what I'd like to see is a serious debate on this issue
> from different aspects, so that in the end, we can say with confidence
> that we've taken a hard look on the issue and here is our conclusion.
> 
> BR,
> Zhigang
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of ext
> > Lars-Erik Jonsson (LU/EAB)
> > Sent: November 19, 2003 09:54 AM
> > To: 'West, Mark'
> > Cc: [email-masked]
> > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp 
> > messages on
> > t he same TCP connection
> > 
> > 
> > I agree with Mark that this is a new and rather controversial
> > new requirement to introduce at this point, especially since
> > we have already closed the issue several times.
> > 
> > /L-E
> > 
> > 
> > > Multiplexing is horrible (or, at the very least messy) 
> > > because you inherently bind the SigComp and SIP transport 
> > > handling for detecting the end of a message.  If you don't 
> > > allow multiplexing, you are free to implement it this way (if 
> > > you want), but if you *do* allow multiplexing then this 
> > > becomes a requirement...
> > > 
> > > But, like I say, I thought that the 'non-multiplexing' issue 
> > > had been agreed.  And it's still not clear to me why it's 
> > > important to be able to do it!
> > > 
> > > Cheers,
> > > 
> > > Mark.
> > > 
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Jan Christoffersson (LU/EAB)
> > > > [mailto:[email-masked]]
> > > > Sent: 17 November 2003 13:47
> > > > To: West, Mark
> > > > Cc: [email-masked]; [email-masked]; 
> [email-masked]
> > > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp 
> > > > messages on
> > > > t he same TCP connection
> > > > 
> > > > 
> > > > Hi Mark,
> > > > 
> > > > Comments inline.
> > > > 
> > > > -----Original Message-----
> > > > From: West, Mark [mailto:[email-masked]]
> > > > Sent: den 14 november 2003 15:09
> > > > To: Jan Christoffersson (LU/EAB)
> > > > Cc: [email-masked]; [email-masked]; 
> [email-masked]
> > > > Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp 
> > > > messages on
> > > > t he same TCP connection
> > > > 
> > > > 
> > > > 
> > > > Hi Jan,
> > > > 
> > > > Comments added!
> > > > 
> > > > Cheers,
> > > > 
> > > > Mark.
> > > > 
> > > > >
> > > > > 1. The extra delay caused by opening and closing TCP 
> > > > connections when
> > > > > switching between SIP and SigComp should not be neglected. 
> > > > In some cases
> > > > > it may be of little concern but in others it may be 
> > > > important. Reducing
> > > > > delay has been the most important driving factor for SigComp.
> > > > > Multiplexing over the same connection reduces the delay.
> > > > >
> > > > 
> > > > But most of the cases where you want to switch between SigComp /
> > > > non-SigComp are inherently cases where there is 
> inherent latency.
> > > > 
> > > > [JC]I agree that these cases will probably have a lot of 
> > > > latency, so this argument isn't very heavy. Still, less 
> > > > latency is better.
> > > > 
> > > > And RFC 3261 (if I read it correctly, but I'm no SIP guru), 
> > > > talks about
> > > > only try to keep a transaction within in a single connection...
> > > > 
> > > > > 2.  We have the tools needed for multiplexing SigComp and 
> > > SIP on the
> > > > > same TCP connection. Why not do it? It's faster than 
> > opening a new
> > > > > connection.
> > > > >
> > > > 
> > > > But the 'tools' are horrible!  Reiterating the sentiments 
> > > > from S-F: 'yeah,
> > > > you could, but why would you want to..?'
> > > > 
> > > > [JC]I don't know why this is so horrible? Could you please 
> > > > elaborate...
> > > > 
> > > > > 3. Mark argues that if multiplexing is allowed, the 
> > > > receiver needs to
> > > > > support it. But doesn't it already need to do this? As 
> > > > Zhigang pointed
> > > > > out, RFC3486 states that
> > > > >
> > > > > "If a SIP client sends a compressed request and the client 
> > > > transaction
> > > > >    times out without having received any response, the 
> > > client SHOULD
> > > > >    retry the same request without using compression.  If 
> > > > the compressed
> > > > >    request was sent over a TCP connection, the client 
> > > > SHOULD close that
> > > > >    connection and open a new one to send the uncompressed 
> > > request."
> > > > >
> > > > > In this text, it says SHOULD and not MUST, i.e. there could be
> > > > > implementations that send SIP and SigComp on the same TCP 
> > > > connection, so
> > > > > all implementations should be able to handle it. In any 
> > > > case, we have
> > > > > delimiters to determine where SigComp messages start and 
> > > end, and if
> > > > > there is something other than SigComp in between an end and 
> > > > a start, we
> > > > > should be able to handle it.
> > > > >
> > > > 
> > > > That is slicing a semantic a shade too thin for me!  But, if 
> > > > you want to
> > > > play word games, then I'll point out that 'uncompressed' does 
> > > > not mean 'do
> > > > not use SigComp'.
> > > > [JC] I didn't intend this to be a word game. To me this is a 
> > > > recommendation to open a new TCP connection. I'm perfectly 
> > > > happy with that. But I don't think we should turn the 
> > > > recommendation into a must and forbid sending SigComp and 
> > > > non-SigComp on the same TCP connection.
> > > > 
> > > > Carsten & I have whipped up a nice little 13-byte 
> standard header:
> > > > 
> > > >   0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22,
> > > >   0x86, 0x01, 0x16, 0xf9, 0x23, ...
> > > > 
> > > > that will simply output the following bytes!
> > > > 
> > > > It's a SigComp message, but there's no compression...
> > > > 
> > > > [JC]Yes, this is perfectly fine, unless the message is larger 
> > > > than 64 K. 
> > > > 
> > > > And let's not forget that the purpose of 
> > > > draft-ietf-rohc-sip-sigcomp is to
> > > > fill in the missing pieces of the mapping jigsaw (i.e. 
> > the bits that
> > > > aren't in RFC 3486).  And that's what we're arguing about.  
> > > > (Although I
> > > > was fairly sure that we'd already decided this.  *sigh*)
> > > > 
> > > 
> > > _______________________________________________
> > > Rohc mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/rohc
> > > 
> > 
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc
> > 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: "West, Mark" <[email-masked]>
Date: Thu, 20 Nov 2003 22:28:28 +0000 (GMT Standard Time)

Hi all,

If you want a different take on this question, how about this...

We seem to be addressing 2 questions: (1) is multiplexing of SigComp /
non-SigComp messages over TCP *generally* useful; (2) is this useful in a
constrained environment with an IPsec SA between peers..?

Considering (2), something that has not yet been raised is the use of what
is sometimes referred to as 'continuous mode'.  The state model in RFC
3320 exists for 2 reasons: lack of security between end-points; and
(potential) lack of reliability.  The IPsec SA and use of TCP renders both
of these non-issues.  So, why not have a persistent UDVM..?

This is perfectly reasonable within RFC 3320 -- there is no need for
state-storage, as the UDVM is simply kept running.

Since, in this model, there is no need to align SIP messages with SigComp
boundaries, the 64kbyte limit need not apply: SigComp ends up simply
providing a compressed TCP stream...
... so connection close semantics are preserved...

Failures essentially become desynchronisation problems (as could occur
with regular SIP), requiring reset of the TCP connection.

The sending of low processing cost messages can still be supported by
using the header that was suggested earlier (with the decompressor
explicitly looking for this).

And no need for multiplexing..! ;-)

Cheers,

Mark.

On Thu, 20 Nov 2003 [email-masked] wrote:

> Date: Thu, 20 Nov 2003 15:57:30 +0100
> From: [email-masked]
> To: [email-masked], [email-masked],
>      [email-masked]
> Cc: [email-masked]
> Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on
>     t he same TCP connection
>
> Hi all,
>