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

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

Hi all,

it seems to be different opinions on how to handle SigComp and SIP over TCP. I think that multiplexing over the same TCP connection is a good idea. Of course, there can be situations where it is not wanted, but then, there is nothing stopping you from opening a separate connection. To me, the main arguments for allowing multiplexing over the same TCP connection are

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.

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.

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.

I feel that we should allow multiplexing of SigComp and SIP on the same TCP connection.

Best Regards
Jan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of West,
Mark
Sent: den 13 november 2003 14:57
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [rohc] Re: multiplexing SigComp and non-SigComp messages on the
same TCP connection

Hi Zhigang,

I agree -- you can't beat a good threat... ;-)

Comments, as ever, in-line.

Cheers,

Mark.

> > If you were allowed to have multiple TCP connections or to
> > re-open a new connection easily, why would you want to do
> > multiplexing on a single connection..?
>
> This is the key question. Actually that is one of the questions
> I've asked Robert during our offline discussion. The answers were
> (if I understood correctly):
>
> - Re-opening a new TCP connection means extra delay. I tend
> to agree, since the establishment and tear-down of a TCP connection
> require quite some procedures in the state machine.
>

This is true: there's a 3-way handshake to establish a new TCP connection.
I'm not sure how much of a big deal this is, since most of the conditions
for sending a non-SigComp message involve significant latency
(retransmission; message > 64kbyte; ...)

However, from my reading of RFC 3261 (I am not now, nor have ever claimed
to be any kind of SIP expert; so if anyone wishes to correct this, feel
free..!) you could have a SigComp & non-SigComp TCP connection open...

> - In certain cases, we are not allowed to have multiple TCP connections.
> I learned that this is the case for 3GPP, in particular, due to security
> policy as Robert described earlier. However, it is unclear to
> me if it is simply a bad choice made by 3GPP, or it is due to some
> technical reasons that are more generic than 3GPP. This is something
> I would like to figure out during this discussion.
>

My personal opinion is that this security model is broken.  It is usual to
have ephemeral source ports and I can't see how it helps to nail down the
source port.  RFC 3261 section 18 says that the source port is 'often
ephemeral'.  Moreoever, 3261 describes having a 'dwell time' for a
connection to allow a transaction to complete within a single connection.
After this time, the connection is/can be closed.  The 'fixed port' model
means that you can't re-open a connection within the time-wait time...

... also all the text in section 18 about error conditions and re-opening
connections seems to be rendered unusable in this scenario...

> > This implementation suggestion:
> >
> > > > A possible implementation could be:
> > > > -	Transport looks at the first byte of the message, and
> > > > cheks whether it starts with 11111.
> > > > -	If yes, the stream is passed to SigComp that reads it
> > > > till 0xFFFF and returns
> > > > -	If no, the stream is passed to SIP that reads it as
> > > > long as indicated by Content-Length
> > > > -	Rinse, Repeat
> >
> > makes it sound easy, but the throw-away 'is passed to' seems to me to
> > conceal all of the complexity / layering problems / tricky stuff...
>
> I do agree this doesn't look nice in the layering diagram. However,
> I don't think it is complex or tricky to implement. SigComp already
> requires quite interactions with SIP layer anyway. Or, perhaps I
> missed something here?
>

I agree that there are significant interactions between SIP and SigComp.
However, these are all defined in RFC 3320.  The point is that SigComp
should (from a transport perspective) be able to look (mostly) like an
alternative transport for SIP.  Multiplexing really breaks that model.

I think my point is that *not* allowing multiplexing means that you can
separate the implementation details.  (You don't have to if you don't want
to, but you *can*).  If you insist on allowing multiplexing, then a
receiving endpoint *must* support it, and that's going to put a bunch of
constraints and requirements on the implementation.  I don't think that
those constraints need to be there, and so I'd prefer not to have them...

_______________________________________________
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: Fri, 14 Nov 2003 14:09:16 +0000 (GMT Standard Time)

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.

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

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

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

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