[rohc] draft-ietf-rohc-sigcomp-04.txt

["Miguel A. Garcia" <[e-mail]>]

Hi:

I have just read the new SigComp-04,
http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-04.txt
and I have some questions and comments.


1) Section 1, Introduction, 5th paragraph:

   "However, 
   SigComp is designed to run over both connectionless and connection-
   oriented transports and hence may be applicable to other scenarios 
   with multiple endpoints compressing and decompressing data."

   I don't see the connection of the "conntectionless/connection 
   oriented transport" with the scenario where there is a single proxy
   for inboud/outbound signalling scenario, or when there are multiple
   endpoints sending signalling end-to-end.

   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.

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

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.
    
   The end-to-end scenario is solved by the application encrypting
   certain header field values. Note that there is not need to 
   encrypt the whole message (otherwise proxies can't route it).
   Encryption of the certain header field values can be done at 
   the application layer prior to sending the message to the 
   SigComp layer.

   The hop-by-hop encryption is applied to the whole message,
   independently on whether the message is sent uncompressed or
   compressed. Further more, the encryption of the message could 
   be done at the link layer or even through some hardware device.

   I would like to hear comments on the above statements. And 
   certainly clarify what is the relationship between the application
   and SigComp. Particularly it needs to be clarified which layer
   is responsible to forward the message: the SigComp layer or the
   application layer.

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 allows to demultiplex application messages 
   based on the port number. For instance, SIP/SigComp messages
   should be addressed to port number X, whereas HTTP/SigComp 
   messages should be addressed to port number Y. This approach
   have the following advantages.

   - Allows a clean SigComp discovery mechanism at the application
     layer (e.g., based on SRV of NAPTR records).
   - The SigComp layer does not need to understand and look inside
     the payload (the decompressed message) to find out to which
     application the uncompressed message should be sent.

   At least, I believe that the SIP WG is moving with the assumption
   that the SigComp layer that is listening to a port is dedicated
   to receive SIP compressed messages.

   Therefore, my proposal is to modify figure 1 and paint just a
   single application and add some text explaining the figure:

   "Several applications may want to use the services provided by 
   a SigComp layer. Each application will need its own instance of 
   the SigComp layer. This restriction is introduced for the purpose 
   of describing the SigComp architecture and it does not mandate a 
   particular implementation.

   The SigComp layer is listening to a port number that is allocated 
   exclusively to receive SigComp compressed messages destined to the 
   application making use of the SigComp layer."

5) Section 3.2, first paragraph:

   "The two instances of the 
   application that wish to communicate MUST initially agree on a common 
   set of values for these parameters."

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

   Or did I misunderstand??

6) Section 3.2, second paragraph.

   "Note that if a reverse channel is available then SigComp can perform 
   an internal "capability announcement" to indicate that additional 
   memory or CPU cycles are available. This means that it is generally 
   sufficient to set fixed values for each application defined parameter 
   (there is no need to provide an external, application-specific 
   negotiation mechanism). "

   I don't understand this paragraph. Can somebody tell me what is meant?

7) Section 4.1.1, first paragraph:

   "An endpoint that wants to send compressed data to a remote party must 
   initialize a SigComp layer at the local party prior to its use,..."

   I believe that there are two different things to say here:
   a) The local application MUST initialize the local SigComp layer

   b) The local SigComp compressor MUST initialize the remote decompressor.

   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,..."
    
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.

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.

10) Section 5.3., last paragraph

   "If a compression failure occurs when compressing a message then the 
   compressor informs the dispatcher and takes no further action. The 
   dispatcher can then report this failure to the application. "

   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. The application may try to other things,
   like sending the message in "uncompressed" mode (better to deliver
   uncompressed messages than not delivering anything at all).

   Suggested paragraph:
   "If a compression failure occurs when compressing a message then the 
   compressor informs the dispatcher and takes no further action. The 
   dispatcher MUST report this failure to the application. The application
   may try other methods to deliver the message."

   Note that the "may" in the last sentence is lowercase, as it does not
   contain normative text, because it affects the application.

11) Section 6.3 Capability announcement

    Question: is this section describing the "Capabilities Announcement" 
    already described in section 4.1.1 ??

    Either we say clearly that it is the same, and we synchronize the
    names (singular vs. plural), or we change one of the names to
    make it clear.

12) Section 6.3., figure 5.

    The figure refers to a Capability announcement "block". What is a 
    block??? It is not defined anywhere. We should make the terminology
    consistent, and therefore, speak about messages, compressed messages,
    compressed data, or similar.

13) Section 8.2, first paragraph.

   "The END-MESSAGE instruction indicates that the compressed message has 
    been successfully decompressed and passed to the dispatcher. Note 
    that the actual uncompressed message is outputted beforehand using 
    the OUTPUT instruction; this allows the UDVM to output each part of 
    the message to the dispatcher as soon as it has been decompressed. "

    I think I am missing something with the last sentence, "each part of
    the message". I thought that if use UDP, one application message 
    equals one UDP packet. If we use TCP, we have delimiters, and one
    application message is delimited. Therefore, what is the UDVM going
    to output to the dispatcher that is NOT an application message???
    In other words, I don't see the possibility of the UDVM outputting
    something else that is not a full, complete application message.
 
That's all.

Thanks a lot,

  Miguel
   

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[e-mail]     Phone:  [phone]
mailto:[e-mail]        Mobile: [phone]

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