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

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 10 Oct 2003 15:34:39 +0100

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

---

From: Pekka Pessi <[email-masked]>
Date: Sat, 18 Oct 2003 01:57:24 +0300

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.

	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