Subject: RE: [rohc] WG last-call for SIP/SigComp

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 2 Nov 2006 15:59:58 -0000

Hi All,

Here are my CDR comments on SigComp for SIP.  I haven't read the other
comments so that I could do an independent review.

The nits are in a separate section at the bottom.

Best regards,

Abbie

Abstract and introduction:
"Any implementation of SigComp for use with SIP must confirm to this
document." 
This sentence appears in the introduction too.  What does this mean
without the must being a MUST (I realise it shouldn't be a MUST in the
abstract)?  What does this mean for legacy implementations /
implementations conforming to other specifications e.g. 3GPP TS24.229?

Introduction:
"Additionally, it must support ...[3485] and ...[3486]."
Again no standards language.  Support for 3485 is specified further on
in the document (so I think isn't needed here) but support for 3486
isn't so what does this mean for support of that RFC?

Section 3.1:
I know the 'reason' part here but I think it should be written more
clearly (I think if you were new to it you'd have to read it several
times).  Add another sentence to explain the example.  Also, the SigComp
user guide refers to 'circular buffer' not 'ring buffer' so it may be
worth using 'circular buffer' here (ring buffer isn't used anywhere
else).

Section 3.2:
The main argument seems to be for a non-zero SMS (rather than for a
particular value).  That's fine, but the argument seems a bit jumbled.
The arguments seems to be:
 * 'non-zero SMS removes uncertainty' - that's not strictly true because
the application can still refuse state creation.
 * Stateless SIP implementations are unlikely to do SigComp - fair
enough
 * 2K per compartment isn't a huge overhead for a stateful
implementation - ok, but see also later point on section 6
 * Compressors making use of 'initial state memory' must use NACK - this
paragraph doesn't really fit here for two reasons:
	1) It's an issue which is orthogonal to the minimum value of
SMS: it's always ok to create state on the first message, the question
is whether you can reference it - in particular if you don't get a
response before sending the next message.  And the answer to that is
related to the presence or absence of NACK, not the value of SMS.
	2) NACK is mandatory anyway

Section 3.5:
Add a statement that because the static dictionary is mandatory it does
not need to be advertised (last point in this email discussion
http://www1.ietf.org/mail-archive/web/rohc/current/msg04463.html).

Section 6:
I have some concerns about this section.  As I understand it:
 * The SIP/SigComp application idendifier is used as a compartment
identifier (I think this should be stated before the discussion about
how to generate SIP/SigComp application identifiers)
 * Compartments SHOULD be created at the beginning of a transaction
 * Compartments *can* be created at the beginning of a registration
 * Compartments *can* be created at the beginning of a dialogue
 * Where a compartment already exists its lifetime is extended to be the
superset of the lifetimes.

If my understanding is correct then I have the following concerns:
 * How do the endpoints know whether a compartment is being created for
a transaction, a registration or a dialogue?  The endpoints must know
exactly when to create a compartment (requiring MUSTs in the
description)
 * If the above is tidied up in terms of MUSTs and SHOULDs, I'm not sure
what it buys you.  You effectively end up with a compartment that lasts
the duration of the registration (with the possibility of including a
dialog that falls off the end of the registration lifetime - is this
allowed and, if so, how likely is it to actually happen?)
 * An SMS of 2K is not a lot in terms of achieving a good compression
ratio - 4K can make a significant difference, but if you have to have 4K
for every registered user, that's a lot of memory
 * The descriptions in sections 6.4, 6.5 and 6.6 are written in terms of
routing headers rather than SigComp terms which make them hard to
understand from a SigComp perspective (I realise most SigComp
implementers may well be SIP implementers, but I'm not ;-) ).

Section 6.3: 
Paragraph about keeping state beyond the end of the compartment.  I was
going to provide some extra text on this to ensure that it is in line
with the discussion in the SigComp Implementer's guide.  I think this
paragraph still needs some clarification about use of advertisements.
At the same time, with the above understanding of compartment
definition, I think this mechanism is less useful/necessary than I
previously thought.

Section 10:
I think section 10 should either be part of section 6 or become section
7 (preferably the former) because it is an example of compartment
creation and deletion.

Nits:

Section 3: page 3
"Note: a SigComp endpoint MAY offer additional resources if available;"
- make clear that it's additional over and above the minimum values
specified in this document rather than the basic SigComp minimum values.

Section 4: second paragraph:

"For a message-based transport such as UDP or SCTP, this can be done per
message."
->
"For a message-based transport such as UDP or SCTP, distinguishing
between SigComp and non-SigComp messages can be done per message."

Section 4: third paragraph:

"For a stream-based transport such as TCP, this can be done per
connection."
->
"For a message-based transport such as UDP or SCTP, distinguishing
between SigComp and non-SigComp has to be done per connection."

Section 4: final note:

Refers to 'a SigComp structured TCP connection' - I think the word
structured is unnecessary and mildly confusing in this note.

Section 6.1:
"Incoming responses: the remote application identifier is the same as
the one of the previously-sent request that initiated the transaction
the response belongs to."
-> 
"Incoming responses: the remote application identifier is the same as
that of the previously-sent request that initiated the transaction to
which the response belongs."

"Outgoing responses: the remote application identifier is the same as
the previously-received request that initiated the transaction the
response belongs to."
->
"Outgoing responses: the remote application identifier is the same as
that of the previously-received request that initiated the transaction
to which the response belongs."

Section 6.3: second paragraph 
"If following..." -> "If, following"

Section 10:

There are several references to section 6.4 which I think should be
references to 6.5 (two on page 15) or 6.6 (one on page 16).

comparment -> compartment (6 instances in section 10 and 1 in section 9)

> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: 13 October 2006 14:40
> To: [email-masked]
> Subject: [rohc] WG last-call for SIP/SigComp
> 
> 
> Soon after the publication of SigComp (RFC 3320), work with a 
> document defining the specifics of using SigComp for SIP 
> message compression was initialised. For various reasons, the 
> finalisation of this document has taken much more time than 
> anticipated, but me and the authors now believe it should be 
> ready for publication. This is an essential document for the 
> application of SigComp on SIP, and it is thus important that 
> we finally get it out of the pipe. We are therefore now 
> issuing a working group last-call on the following document:
>  
>              draft-ietf-rohc-sigcomp-sip-03.txt
>                   (for publication as Proposed Standard)
>  
> This will be the usual two-week WG last-call as suggested in 
> RFC 2418. Please direct last-call comments to the ROHC 
> mailing list [email-masked] before Fri, 2006-10-27, 18:00 UTC.
>  
> /L-E
> 
> --------------------------------------
> Lars-Erik Jonsson
> IETF ROHC WG Chair
> E-mail: [email-masked]
> Phone: +46 8 404 29 61
> 
> My opinions are my personal opinions and should not be 
> considered as the opinions of my employer, if not explicitly stated.
> 
> _______________________________________________
> 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: cco <[email-masked]>
Date: Mon, 6 Nov 2006 14:16:13 +0100

> exactly when to create a compartment (requiring MUSTs in the

cristian: on an P-only box will be quite tough to get a registration
compartment right...

> for every registered user, that's a lot of memory

cristian: now, I guess you see this too black and white. in my oppinion
all this mapping is trying to achive better compression (longer
compartment lifetime if used properly can lead to better compression).
but you can have a policy like: 

- this (register) compartment was not used for this long _and_
- I am running out of memory
- then destroy it.

if the client uses NACK correctly it can recover from trying to access
lost state on the proxy (at the next request/transaction).

bye now!
cristian