Subject: RE: [rohc] draft-ietf-rohc-sigcomp-04.txt

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Wed, 20 Feb 2002 13:49:54 +0100

Hi Miguel,

Thanks for your comments. I've tried to provide you with some answers. 

> 1) Section 1, Introduction, 5th paragraph:
>    I would suggest to rephrase and split the sentences into different 
>    paragraphs, one describing the scenario that SigComp is trying to
>    solve (an endpoint - proxy scenario) and the other describing the
>    ability of SigComp to run over connectionless and c.o. transports.

Is it ok if we just split the sentence as:

"This document focuses on the signaling scenario where an endpoint 
 sends and receives data to/from an outbound/inbound proxy. However, SigComp
 may be applicable to other scenarios with multiple endpoints 
 compressing and decompressing data.
 
 SigComp is designed to run over both connectionless and connection-
 oriented transports."

> 2) Section 2, Terminology, definition of Application:
> 
>      "c) decides whether state information may be saved by SigComp "
> 
>    I believe that the application does not decided to save state
>    information, but the application "authorizes to save state 
>    information based on a request from the SigComp layer".

I guess we could make the change as you suggest.

"c) authorizes to save state information based on a request from the SigComp layer"
 
> 3) Section 3, SigComp architecture, 2nd paragraph:
> 
>    "SigComp is typically offered to applications as a "shim" layer 
>    between the application and the transport. Note however that for 
>    certain applications the compressed SigComp message may be passed 
>    back to the application itself for additional processing before 
>    transmission. For example, the application may wish to apply 
>    encryption to the compressed message before handing it to the 
>    transport. "
> 
>    I don't think this scenario is possible. To my understanding, 
>    there are two types of encryption: end-to-end and hop-by-hop.

This roles back to whether SigComp is applied IP end-to-end (Endpoint - first proxy ), or "SIP end-to-end" (SIP endpoint to SIP endpoint). 
     
>    I would like to hear comments on the above statements. And 
>    certainly clarify what is the relationship between the application
>    and SigComp. 

I think this comes back to which scenario we want to solve. If it is the SIP end-to-end scenario with encryption, this may probably make SIP/SigComp require an assigned port number and SigComp would not be regarded as a shim layer to SIP, but the implementation would have to be totally integrated. 

>    Particularly it needs to be clarified which layer
>    is responsible to forward the message: the SigComp layer or the
>    application layer.

With my current understanding of our work and if it is as you say then I think it does not make sense to pass up a compressed message to the application to forward the SigComp message.  
 
> 4) Section 3, SigComp architecture, Figure 1.
> 
>    The figure shows 2 different applications. In my mind, there 
>    should be one and only one application, together with a text 
>    that describes that there is one SigComp layer instance per
>    application.

This approach seems to have some good and valid arguments along with it. 

> 5) Section 3.2, first paragraph:

>    In order to avoid confusion with two applications running in the
>    same local host and making use of SigComp, I would suggest 
> to rephrase:
> 
>    "The local and remote applications that wish to communicate MUST 
>    initially agree on a common set of values for these parameters."
 
I think this is a good suggestion.
 
> 7) Section 4.1.1, first paragraph:
> 
 
>    As a minimum, the above sentence should be rephrased as:
> 
>    "An endpoint that wants to send compressed data to a 
> remote party must 
>    initialize a SigComp layer at the remote party prior to 
> its use,..."

This is good for clarification.

>     
> 8) Section 4.2, first paragraph:
> 
>    "The basic SigComp message consists of a block of UDVM 
> bytecode, the 
>    first n bytes of which are interpreted as a state identifier that 
>    accesses some previously stored state information. "
> 
>    I think this is inherited from the UDVM draft and it is not valid 
>    anymore. The basic SigComp message will NOT consist only of UDVM
>    bytecode. Whatever the basic SigComp message is made of, should be
>    reflected in the paragraph.

There is a note in the draft about solving the identification of different types of messages by reserving state identifiers. However, I now think that this is not possible for the following reason:

* SigComp do not know the length of the state identifier prior to the capability announcement.
- As SigComp does separate flows, SigComp needs to carry the hash length for each message. 

I think this make it valid to introduce some bits to identify the particular message type. Thus, the basic SigComp message format would change to something like this:

     0   1   2   3   4   5   6   7 
   +---+---+---+---+---+---+---+---+ 
   |  MT   |Reserv.|  hash length  | 
   +---+---+---+---+---+---+---+---+ 
   |                               | 
   :   state_identifier (n-bytes)  :  
   |                               | 
   +---+---+---+---+---+---+---+---+ 
   |                               | 
   :    Remaining UDVM bytecode    : 
   |                               | 
   +---+---+---+---+---+---+---+---+ 

The MT, Message Type, would indicate what type of message it is, e.g. SigComp request/announcement, "ordinary" SigComp compressed message.

> 9) Section 4.3, 7th paragraph:
> 
>    "Uncompressed data is also outputted by the UDVM using a specific 
>    instruction. Depending on the particular application, the 
> dispatcher 
>    decides whether to forward a partially decompressed message 
>    immediately to the application, or to buffer and wait for 
> a complete 
>    message to be successfully decompressed."
> 
>    I disagree with the above statement. The decompressor dispatcher I
>    have in my mind does not have any application knowledge. It is,
>    therefore, not able to distinguish whether the message is complete,
>    or partly received. The dispatcher should limit to pass 
> decompressed
>    data to the application. The application must be aware of 
> whether the
>    received message is complete or not.
> 
>    Therefore, I suggest to remove the mentioned paragraph.

I tend to agree with you on this. As a decompression failure/success check is done on the whole decompressed message this statement contradict this.

 > 10) Section 5.3., last paragraph

>    I think the last sentence should replace a "can" with a "MUST". 
>    In case there is a problem to compress a message, it is a MUST that
>    the application is informed. 

I think you're right on this.

> 11) Section 6.3 Capability announcement
> 
>     Question: is this section describing the "Capabilities 
> Announcement" 
>     already described in section 4.1.1 ??

Those sections are related, and we should synchronize the names.

> 12) Section 6.3., figure 5.
> 
>     The figure refers to a Capability announcement "block". 

Yes, we need to define the term "block". What do you think about the following:

"Capability announcement block"
formatted capability announcement information

> 13) Section 8.2, first paragraph.

See my comment to bullet 9).

BR
/Hans H

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 21 Feb 2002 23:45:36 +0200

Hi Hans and the rest of the rochers:

I think Hans already agreed on some of the points, so I will comment only
on those that I think we didn't get an agreement yet. 

> I think this comes back to which scenario we want to solve. If it is the SIP end-to-end scenario with encryption, this may probably make SIP/SigComp require an assigned port number and SigComp woul…

<Miguel> I think that still is not clear to me the relation or problems with
the encryption. Let's imagine the typical SIP trapezoid, that is, two endpoints
A and B communicating with two other proxies (P1, P2) in the middle. So the
chain is A - P1 - P2 - B

Lets assume that SigComp is running between A and P1.

The SIP layer in A builds a SIP message. As the end receiver is B, and A wants to send
some very secret information that only B is able to read, A decides to encrypt that 
information with some secret key so that the information is only decoded by B. Note 
that those SIP header field values that are sensitive to be used by proxies during
routing MUST not be encrypted, otherwise, P1 and P2 can't route the message. 

So A has a SIP message destined to B (through P1 and P2) where certain header field
values are encrypted. This message is passed to the local SigComp shim layer. Sigcomp
compresses the message. After that, there may be other encryption mechanism that run
between A and P1, such as TLS or some other encryption layer. SigComp passes the 
message to the "hop-by-hop encryption layer", whatever that is.

This what I was thinking all about. This mechanism allows end-to-end encryption of
certain values, and hop-by-hop encryption of the whole message. And it does not
require to return a compressed message back to the application (as I understood in
the original text).

I believe this covers all the requirements for encryption.

</Miguel>

> With my current understanding of our work and if it is as you say then I think it does not make sense to pass up a compressed message to the application to forward the SigComp message.

<Miguel> I agree. Imagine that the SIP layer receives a SIP compressed message. It will fail to
parse the message. That is for sure. There is nothing SIP can do with a compressed message.

</Miguel>

> I think this make it valid to introduce some bits to identify the particular message type. Thus, the basic SigComp message format would change to something like this:

<Miguel> I was thinking that you would need a Message Type as you were pointing
out. If we would agree on this, I would say that 2 bits seems to be a little
bit constraining... It allows for a maximum of 4 message types. That seems to 
be very limiting. Perhaps you need 3 bits as a minimum.
</Miguel>

> formatted capability announcement information

<Miguel> My question is: do we need to introduce a new concept "block" in the
draft? If there is a need or it clarifies something to the reader, it is fine.
But it seems difficult to justify that you don't need the "block" concept until
section 6.3, but you needed afterwards.
</Miguel>

Regards,

    Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002