Subject: RE: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt

From: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Tue, 14 Oct 2003 09:05:31 +0200

Hi Abbie,

I agree with you that a mandatory DMS of 8K seems to be unnecessarily large, 4K seems to be more suitable as mandatory requirement. We should not forget that it's always possible for an endpoint to offer more.

BR
Jan

-----Original Message-----
From: Surtees, Abigail [mailto:[email-masked]]
Sent: den 10 oktober 2003 16:35
To: [email-masked]'
Subject: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt

Hi Folks,

Here is the requested review of draft-ietf-rohc-sigcomp-sip-00.txt.  Some
comments are minor nits, others are larger issues that may require further
discussion.  

Issues for discussion:

Page 3: 
		Section 2.1

My gut feeling is that 8k seems rather large for DMS.  For TCP the size of
the message sent has no impact.  For UDP, following the SIP instruction that
a SIP message should not be within 200 bytes of the MTU the maximum size of
a SigComp message is 1272 (assuming a 1500 byte MTU).  The worst case is
that where C is really small and B and S are large.  So we have C + B + S <=
1272 with a worst case of B + S = 1272 and C = 0 because B and S count twice
(cannot quite be achieved but is useful to make the point).  So C + 2B + 2S
+ 128 = 2672 which with a DMS of 4k still leaves 1328 bytes for R. 

The other thing to take into consideration is whether there is any point in
mandating an 8K DMS but only a 2K SMS?  8K allows R to be large but then the
whole history cannot be stored because SMS is not big enough?

Your thoughts?

		Section 2.2

Mandating an SMS of 2k would prevent the use of SigComp with a stateless
proxy.  Is this necessary?  A SigComp endpoint may not assume that state
will be stored until it has had an advertisement of SMS.  However, it can
request it and ensure that it waits for an acknowledgement before using the
state.  Presence of an SMS of 2k does not ensure that the state will be
created, it just ensures that there is potential for creating state.
Consequently is there any need to mandate it?

An alternative may be to say that if SMS is going to be advertised, it
should be at least, for example, 4k.
This would then not preclude stateless SIP proxies from running with
SigComp.

Page 5:
		Section 3 cont.
Paragraph 1:	I agree with the editor's note.  The definition of
compartments and description of how long state can persist is complicated
and needs discussion and further work on the mailing list.

Minor nits:

Page 1:	
		Abstract:
I felt that this was not particularly clear, in particular, the use of the
word 'specifics' and the fact that there were references that were not
explained.

Suggested text:

"This document describes default parameters and definitions for use when
Signaling Compression (SigComp) is applied to the Session Initiation
Protocol (SIP).  Any implementation of SigComp for use with SIP must conform
to this document, in addition to SigComp and use of the SIP static
dictionary."

Page 2:
		Introduction:

Similar phraseology not clear in paragraph 2 and references aren't clear.  

Suggested text:

"This document binds ... SigComp).  Any SigComp implementation that is used
for the compression of SIP messages must conform to this document, as well
as to SigComp [RFC 3320] and must use the SIP static dictionary as specified
in [RFC 3485].

Note:  The mechanism for discovery of SigComp support at the SIP layer is
specified in [RFC 3486]."

		Section 2:
Paragraph 1, 3rd line "when receiving Sigcomp messages" - confuses rather
than clarifies.  IMHO the sentence makes sense without it.

Paragraph 1, last sentence "Scalability is ..." should be "Scalability was
..."

Page 3:
		Section 2.2
Paragraph 3, line 3 - "of whether it can" should be "of whether or not it
can"

Page 4:	
		Section 2.5
"Minimum value" doesn't make sense for the static dictionary.  Should be
"For ..." as in 2.4

		Section 3
Paragraph 4, line 3 - "However, the actual presentation", should be
"However, the actual representation".

Page 6:
		Section 4 cont.

Paragraph 2 - suggested addition to the end of the last sentence "and be
delimited by the use of 0xFFFF as described in [RFC 3320]."

Abbie Surtees
Engineer
Networks
Roke Manor Research Ltd
Old Salisbury Lane
Romsey, SO51 0ZN
Tel:   +44 (0) 1794 833131

_______________________________________________
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: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Thu, 23 Oct 2003 11:42:32 +0200

Hi Pekka,
In general, I don't think that anyone can argue against that the more DMS and SMS you have available the better. However, the point with this draft is what the MANDATORY minimum DMS and SMS parameters for SIP compression should be! I think that the mandatory requirements should not be the "optimal" parameter values but instead values that give a reasonable performance. If an entity has the ability to give a larger DMS size than the mandatory value, it is free to do so.

more comments inline.

BR
Jan

-----Original Message-----
From: Pekka Pessi [mailto:[email-masked]]
Sent: den 18 oktober 2003 00:57
To: [email-masked]'
Cc: Abigail Surtees
Subject: Re: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt

Surtees, Abigail <[email-masked]> writes:
>a SigComp message is 1272 (assuming a 1500 byte MTU).  

	The limitation is true for requests. However, responses can
	easily be greater than that, or even bigger than MTU.

>The worst case is that where C is really small and B and S are large. 
>So we have C + B + S <= 1272 with a worst case of B + S = 1272 and C =
>0 because B and S count twice (cannot quite be achieved but is useful
>to make the point). So C + 2B + 2S + 128 = 2672 which with a DMS of 4k
>still leaves 1328 bytes for R.

	Don't forget SIP dictionary (D), which can be 4832 bytes.

	If B + S = 1500, then C + 2B + R + 2S + 128 + D < DMS leaves us
	with R < DMS - 2B - 2S - C - D - 128 or R < 2932 bytes in case
	of DMS=8192. I can't agree that 4096 is plenty.

[JC] In case the SIP dictionary is used, I think this should be contained in S. Even if this dictionary is 4.8 K, it is not necessary to use all of it. In fact, after a couple of message exchanges it will not contribute very much to the compression performance. To use the static dictionary for dimensioning the DMS does not seem to be a good idea.

	But in any case I think DMS is cheap, as it's active only during
	decompression for UDP, and nothing compared to the socket
	buffers required by TCP.

>proxy.  Is this necessary?  

	I don't see any reason why a stateless proxy cannot create
	state. It just don't keep transaction state.

>A SigComp endpoint may not assume that state

	I agree, 2k can be rather crowded.

....
>and needs discussion and further work on the mailing list.

	Definitely.
	
					Pekka

---

From: [email-masked]
Date: Thu, 23 Oct 2003 16:23:21 -0400

Hi Abbie,

Thanks for your comments, especially after such a long silent
period on the subject in this mailing list.

To make the reply shorter, I'll comment below only on the easy ones 
(i.e. nits). I'll address your comments on SMS and DMS in a separate email.

BR,
Zhigang

> to this document, in addition to SigComp and use of the SIP static

I agree the current text is not particularly clear. However, the text 
above does not cover section 3, 4, and 5. I'll expand above text to
make it broader enough. 
 
> as to SigComp [RFC 3320] and must use the SIP static 

OK. To be more accurate, I'll change it to "SIP/SDP-specific
static dictionary.

> than clarifies.  IMHO the sentence makes sense without it.

OK for me.
 
> Paragraph 1, last sentence "Scalability is ..." should be 

Right. 

> Paragraph 3, line 3 - "of whether it can" should be "of 

OK.

> "Minimum value" doesn't make sense for the static dictionary. 

It is the "minimum value" of locally available state. I used
the term in the broader sense, i.e., minimal data or minimal set 
of data. But I can change the text as above if it is confusing.

> "However, the actual representation".

Yes!

> delimited by the use of 0xFFFF as described in [RFC 3320]."

OK.

---

From: [email-masked]
Date: Thu, 23 Oct 2003 17:58:49 -0400

Hi Abbie,

> My gut feeling is that 8k seems rather large for DMS.  For 
> TCP the size of the message sent has no impact. 

Actually, a small DMS is even a bigger problem for TCP. RFC 3320
specifies that only half of the DMS can be used as UDVM memory. 
Namely, 4KB DMS means 2KB UDVM memory. It is quite limiting
considering all the stuff that has to be stored in UDVM memory:
bytecode, partial SIP/SDP static dictionary (obviously we cannot
use the entire dictionary), other uploaded dictionaries, and 
decompressed data (which is useful to compress/decompress
remaining data in the same message).

> For UDP, following the SIP instruction that
> a SIP message should not be within 200 bytes of the MTU the 
> maximum size of a SigComp message is 1272 (assuming a 1500 byte MTU). 
> So we have C + B + S <= 1272 

Hmm ... this is the upper bound for SIP message over UDP. Did we ever 
specify the same limit for SigComp messages over UDP? If that
is the case, we are in real trouble.

> The other thing to take into consideration is whether there 
> is any point in mandating an 8K DMS but only a 2K SMS?  
> 8K allows R to be large but then the whole history cannot 
> be stored because SMS is not big enough?

See above for the "half" factor in case of TCP. So, it's not
8K UDVM memory vs 2K SMS, but rather 4K UDVM memory vs 2K SMS.
And R (ring buffer size) is even smaller than 4K: R = 4K - 
128 - B (bytecode size). In addition, you probably don't
want to put everything in the ring buffer in a state.

Of course, I don't mind to specify SMS = 4KB, which allows us
to create multiple states from multiple SIP messages. However,
I'm more conservative on SMS than DMS since states stay after UDVM
(i.e. for the whole lifetime of a compartment), while DMS is only
per UDVM alive. 

From my perspective, 2K SMS allows a compressor to create states in 
the first message without guessing if the states will make it at all
on the decompressor side. This is good enough. Like you said, the other
end can always announce larger SMS. And it can do so right in the reply
to the first message ...

BR,
Zhigang