Subject: [rohc] Second WG last-call for SIP/SigComp - dedicated review

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 12 Dec 2006 17:10:18 -0000

Hi All,

Here are my CDR comments on draft-ietf-rohc-sigcomp-sip-04.txt.  I am
surprised to find that some of my comments from the first WGLC have
neither been addressed by email nor addressed in the updated document
(unless the email got missed?)

Those that have been addressed, I've removed from this email.  Those
that haven't are still here with a note.  There are also some new
comments.

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?
[12/12/06] no response

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?
[12/12/06] no response

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).
[12/12/06] no response

Section 3.2:
The arguments now is:
 * '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
[12/12/06]  Some text has been removed from this section which is fine,
but the first point still seems slightly disingenuous and could cause
confusion.

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).
[12/12/06] no response

Section 8.2
Re: Use of IP address and port/connection for the remote application
identifier for legacy systems.  If a client fails (losing all SIP state
including SigComp compartment) and re-REGISTERS with the same IP
address, how can the SIP stack tell that the old compartment is invalid.
I realise that the answer is probably that this circumstance is
relatively unlikely and that NACK would recover the situation, but I
think this should be made clearer.

Section 8.3 
I think this section should be combined with section 8.4.  The
definition of when compartments should be opened and closed needs to be
stronger.  In this section, section 8.4 and section 12, there are strong
echoes of the fact that it used to be possible to have different
compartment lifetimes.
I think there should be standards language (probably SHOULDs) stating
when compartments should be opened and closed.  i.e. compartments SHOULD
last the lifetime of the registration, but leaving the possibility for
early closure and NACK recovery in extreme cases (e.g. overload
conditions).

Section 8.3 (Paragraph about keeping state beyond the end of a
compartment):
This paragraph still refers to compartments lasting the length of a
dialog or transaction!
How useful is the technique described in this paragraph, now that a
compartment lifetime is a registration? 

Section 8.4
See comment on section 8.3 about strengthening compartment definition.
I also think the security implications of opening a compartment on
receipt of a REGISTER should be mentioned.  Compartments and state can
only be created if the application says so, but, particularly if the
decompressing node is a proxy, the non-2xx response may take a while to
be generated.

Section 8.4
"However, applications MAY also choose to keep these
   compartments open for a longer period of time, as discussed
   previously."
Does the 'as discussed previously refer to the 'paragraph about keeping
state beyond the end of a compartment'?  If so, then i) I'm not sure
it's that useful and ii) the wording implies something different.  If
not, then what does it refer to?

Section 8.5
I was surprised to see this section (but maybe I missed it's discussion
on the list).  I can understand softening the 'SHOULD' in RFC3486, but I
don't think it should be a 'SHOULD NOT' - it depends on the stateless
algorithm in use and the size of the message being compressed.  With a
stateless algorithm that has short bytecode and a large message (e.g.
INVITE) it is possible to still achieve non-trivial compression gain.

Section 12:
I think section 12 should either be part of section 8 or become section
9 (preferably the former) because it is an example of compartment
creation and deletion.
[12/12/06] This was a comment about section 10 before.  No response.

As mentioned above several sentences have echoes of the possibility of
having variable compartment lifetime:

"This compartment will be valid, at least, for the
   duration of the registration."
Remove the 'at least'

"The compartment opened by the outbound proxy will be valid,
   at least, for the duration of the registration."
Remove the 'at least'

"Since this URI's SIP/SigComp identifier 'Outbound-id' matches that of
   the compartment created before, this compartment is used to compress
   the INVITE request."
What other compartment could be used?

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.
[11/12/06] no response

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."
[12/12/06] no response

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."
[12/12/06] no response

Section 4: final note:

Refers to 'a SigComp structured TCP connection' - I think the word
structured is unnecessary and mildly confusing in this note.
[12/12/06] no response.  Alternatively make it 'SigComp-structured'

Section 7: 
Phraseology 'failure occurred to' and 'loss occurred to' feel slightly
clumsy.
Rephrase to:
'failure occurred on' and 'If the response was lost, ...'

Section 8.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."
[12/12/06] was section 6.1; no response

comparment -> compartment (1 instance in section 8.3 and 1 in section
11)

Section 8.4: last paragraph
"If following the previous rules" -> "If, following the rules above, "

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

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

---

From: cco <[email-masked]>
Date: Wed, 13 Dec 2006 18:04:15 +0100

> think this should be made clearer.

cristian: since I have seen this situation during testing I guess it is
_not_ relatively unlikely at all.

if we assume a config like:

phone(sigcomp) ---- Proxy (P-CSCF w/ sigcomp) === IMS_cloud

two distinct scenarios are possible here:

1. phone registers sucessfully with the proxy; phone reboots/restarts/or
does whatever which produces a compartment loss. phone comes back online
_within_ the lifetime of the compartment on the proxy (ip/port mapping).
when the proxy will send a compressed message using the compartment (and
assuming existant remote state) the phone will NACK it.

2. same thing but this time the compartment loss happens on the proxy.
the proxy will NACK the first compression packet it sees from the phone
after it is back online.

bye now!
cristian