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

From: [email-masked]
Date: Fri, 14 Nov 2003 17:12:34 -0500

Hi Mark,

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

I don't think Jan is playing word game here. Few people really 
enjoy it. SHOULD and MUST are well defined words in IETF. This
is no point to argue that further. 

RE "uncompressed". Evidently and unfortunately, people used it with 
different meanings in mind. And in fact, it remains arguable if a sigcomp
message encapsulating an uncompressed SIP message can be really called an 
"uncompressed message". One may say it is still a compressed message, 
but with NULL compression algorithm (like the NULL encryption algorithms
for IPsec). This starts looking like a word game, so, I'd better just 
stop here. Anyway, we already agreed to non-sigcomp messages when we
do mean non-sigcomp message. This is not my point.

My point is that when RFC 3261 states: "... the client SHOULD close that
connection and open a new one to send the uncompressed request.",
it *should* mean to send non-SigComp messages on the new TCP connection. 
Logically, if the sender suspects a SigComp failure (see futher below)
has happened, it should avoid using SigComp.

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

Nice code indeed. For those who are wondering, the first 3 bytes
are SigComp header. And the remaining 10 bytes are the decompression
byte code: INPUT-BYTES(1, 64, +9), OUTPUT(64, 1), Jump(-7), 
END-MESSAGE(with zeros operands initialized by UDVM).

This should work fine to resolve the SigComp failures due to state
desynchronization. But what if the UDVM somehow malfunctions so that 
it cannot execute the bytecode correctly? Of course, this should 
rarely happen, but is still a possibility as we're talking about
SigComp failures.

(Also, as a less important issue, it takes time for the UDVM execute
the byte-by-byte I/O instructions. Of course, a smart implementation
may analyze/compile the code instead of interpreting it. But can we
assume that?)

BR,
Zhigang

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

---

From: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Mon, 17 Nov 2003 14:46:39 +0100

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.

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*)

---

From: "West, Mark" <[email-masked]>
Date: Wed, 19 Nov 2003 15:31:10 -0000

Hi Jan,

Yes, less latency is good (that has always been a goal of SigComp).  And I agree that messages > 64kbyte are a problem with SigComp!  Still, you can't win 'em all...

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.

> From: Jan Christoffersson (LU/EAB)
> [mailto:[email-masked]]
> Sent: 17 November 2003 13:47
> To: West, Mark
> [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.
> 
> you want to
> [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.
>

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 19 Nov 2003 16:53:46 +0100

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

---

From: [email-masked]
Date: Wed, 19 Nov 2003 13:12:25 -0500

Hi,

> And I agree that messages > 64kbyte are a problem 
> with SigComp!  

Is this a valid reason to have multiplexing over TCP? 

Consider the scenario where the communication between endpoint A
and B involves both delay sensitive short messages and 
non-delay-sensitive long (> 64KB) messages. Without multiplexing,
two TCP connections are required which leads to issues such as 
synchronization of messages transmitted on the two TCP connections.
 
> handling for detecting the end of a message.  

For a given TCP stream, multiplexing means the receiver needs
to alternate between two parsing "modes": SigComp mode, in which
SigComp controls the parsing of incoming stream, and transparent
mode, in which the application takes control. 

This passing of "controls" between SigComp and application does 
add complexity. But is it really "horrible" or "messy", considering
the binding/interaction between SigComp and application we already
have, such as message authentication, compartment management, 
feedback, etc? 

> If you don't allow multiplexing, you are free to implement it 
> this way (if you want), 

Not really. The sender has to know if the receiver supports 
multiplexing. So, it's not just a matter of implementation.

BR,
Zhigang

---

From: [email-masked]
Date: Wed, 19 Nov 2003 16:01:27 -0500

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

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

---

From: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Mon, 24 Nov 2003 11:13:17 +0100

Hi Mark,

I have some concerns about this too...
Comments inline.

/Jan

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

In order to use the continuous mode and compress messages relative to previous messages, the byte codes need to be tailored for this. This means that we need to know that the receiving endpoint is using continuous mode and this means negotiations. How to do this has not been defined.
 
> 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...

Quoting from the RFC 3320: 

"Decompression failure occurs if the cumulative number of bytes provided to the dispatcher exceeds 65536 bytes."

I think that the word cumulative means that you cannot break a large message into little pieces and output them one by one. As soon as the total size is 65 K a decompression failure occurs. I even think that continuous mode could worsen the situation: If several SIP messages are decompressed by the same instance of the UDVM (which could be done in continuous mode)it could happen that decompression failure occurs even if no single message is above the individual limit.