Subject: [rohc] sigcomp issue lejo-10

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Tue, 2 Apr 2002 16:43:25 +0200

> lejo-10) Extended operations: To support e.g. explicit acks is an
>          implementation issue. However, as SigComp is now 
> defined, this
>          is about having it implemented at both "sides" to get the
>          functionality. What I mean is that to use dynamic compression
>          between compressor1 and decompressor2, compressor2 
> must provide
>          acks for decompressor2 states. Is this a nice 
> solution? Would it
>          not be possible to define SigComp so that compressor1 could
>          implement this by using the right UDVM instructions to force
>          "state acks" for saved state from decompressor2? As 
> it is now, both
>          sides must explicitly implement this to get any 
> benefits, and that
>          is not a nice way of having an implementation option.

Well, we had something that could have been used for this in SigComp-04, i.e. Requested and Returned information. But, I'm not sure if that had worked without at least a modification to the END-MESSAGE instruction. 
However, I've have a vague memory of some discussion in Minneapolis that there may be some security issues with that approach, is there anyone that recalls this?

Anyway, 
the approach in SigComp-05 and Extended-02, i.e. endpoint B decides whether to acknowledge state(s) to endpoint A, seems to work with the current set of UDVM instructions, and I believe it is easier for endpoint B to keep track of what states it has acknowledged, this knowledge may be useful when SigComp is applied in an environment were packet losses may occur. 
Perhaps it is not the "nicest" solution, but as "state-acks" from endpoint B would gain endpoint B as it would gain endpoint A, (often SigComp would be applied in a two-way communication, consider e.g. SIP), then I think both endpoints would be glad to get the message exchange over with as fast as possible. So, I think it is good to keep the approach we have in SigComp-05 and extended-02.

BR
/Hans H

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

---

From: "Price, Richard" <[email-masked]>
Date: Wed, 3 Apr 2002 12:17:42 +0100

> >          implementation issue. However, as SigComp is now defined, this
> >          between compressor1 and decompressor2, compressor2 must provide
> >          acks for decompressor2 states. Is this a nice solution? Would it
> >          "state acks" for saved state from decompressor2? As it is now, both
> >          sides must explicitly implement this to get any benefits, and that
> Well, we had something that could have been used for this in 
> SigComp-04, i.e. Requested and Returned information. But, I'm 
> not sure if that had worked without at least a modification 
> to the END-MESSAGE instruction.
> However, I've have a vague memory of some discussion in 
> Minneapolis that there may be some security issues with that 
> approach, is there anyone that recalls this?

Hi Hans,

I believe that this discussion was with me. The security issue
that I raised was just that a compressor could overload the
reverse channel by making an excessively large number of feedback
requests; however this can easily be solved by only allowing one
feedback request per message and setting an upper bound for the
size of the feedback data.

> Anyway, 
> the approach in SigComp-05 and Extended-02, i.e. endpoint B 
> decides whether to acknowledge state(s) to endpoint A, seems 
> to work with the current set of UDVM instructions, and I 
> believe it is easier for endpoint B to keep track of what 
> states it has acknowledged, this knowledge may be useful when 
> SigComp is applied in an environment were packet losses may occur.

The weakness of the current solution is that the choice of whether
to send explicit acks to Endpoint A or not is made by Endpoint B.
However, we have an alternative solution for acknowledgements (namely
implicit acks); the decision on whether to these or not is made by
Endpoint A.

Since there is no way for Endpoint B to work out what Endpoint A is
doing, we might end up with both ack schemes running over the same
channel. Even worse, we might end up with no ack scheme at all
because each endpoint expects the other endpoint to handle the
acknowledgements.

> Perhaps it is not the "nicest" solution, but as "state-acks" 
> from endpoint B would gain endpoint B as it would gain 
> endpoint A, (often SigComp would be applied in a two-way 
> communication, consider e.g. SIP), then I think both 
> endpoints would be glad to get the message exchange over with 
> as fast as possible.

If Endpoint A is using an implicit ack scheme, then the explicit acks
sent by Endpoint B are wasted. The cost of explicit acks is quite high
(currently 10 - 20 bytes per packet), which is a lot of bandwidth to
throw away for no gain.

> So, I think it is good to keep the approach we have in
> SigComp-05 and extended-02.

I believe that SigComp-06 should have the Requested and Returned
feedback of SigCompo-04. This will need a bigger update to the drafts,
but I think that it is worthwhile because it will be a significant
improvement over the current solution.

Regards,

Richard

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Wed, 3 Apr 2002 14:05:17 +0200

Hi Richard,

> Even worse, we might end up with no ack scheme at all

Well, an endpoint could keep track of what states that are being requested/accessed by the remote endpoint so I do not think that will happen, but it would be a matter of implementation.

Anyway, would the announcement information look something like below in SigComp-06 then?

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
 |          length           |   
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
 |       UDVM_version        |   
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
 |    SigComp parameters     |    
 :                           :
 :                           :
 |                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
 |            n              | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |        id_length 1        | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                           | 
 :        id_value_1         : 
 |                           | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         :         : 
         :         : 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |        id_length n        | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                           | 
 :        id_value_n         : 
 |                           | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 | Requested data length     |  
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
 |                           | 
 :    Requested data         : 
 |                           |             
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
 | Returned data length      |  
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
 |                           | 
 :     Returned data         : 
 |                           |             
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 |                           | 
 :         reserved          : 
 |                           | 
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

BR
/Hans H

---

From: "Price, Richard" <[email-masked]>
Date: Wed, 3 Apr 2002 13:32:32 +0100

Hi Hans,

The receiving endpoint could certainly track the states that are
being accessed and attempt to guess whether explicit acks are needed
or not. However this might take quite a few RTTs, and the endpoint
would also have to download some new bytecode on the fly which is
quite costly.

I believe that the format of the requested feedback should be as
follows:

  0   1   2   3   4   5   6   7       0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
| 0 |    requested_feedback     |   | 1 | requested_feedback_length |
+---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
                                    |                               |
                                    :      requested_feedback       :
                                    |                               |
                                    +---+---+---+---+---+---+---+---+

The returned feedback format should be identical. The reason for the
above encoding is that the requested feedback does not have to be a
state identifier; any message identifier will suffice as long as the
sender does not reuse a MID before it has been acknowledged. The above
encoding is very efficient for the case that at most 128 distinct MIDs
are required (which is typically more than enough).

The SigComp parameters (including the state identifiers for the state
created by the sender) should be announced similarly to SigComp-05.

Regards,

Richard

> -----Original Message-----
> From: Hans Hannu (EPL) [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2002 1:05 PM
> To: Price, Richard; [email-masked]'
> Subject: RE: [rohc] sigcomp issue lejo-10
> 
> 
> Hi Richard,
> 
> Well, an endpoint could keep track of what states that are 
> being requested/accessed by the remote endpoint so I do not 
> think that will happen, but it would be a matter of implementation.
>

---

From: [email-masked]
Date: Wed, 3 Apr 2002 10:09:36 -0600

> size of the feedback data.

... or we could count the feedback triggered by compressor-1 as part
of its state budget. Anyway, a feedback request needs to pass the same 
security check as a state creation request. 

BR,
Zhigang

---

From: [email-masked]
Date: Wed, 3 Apr 2002 18:21:31 -0600

Hi,

Why do we need to standardize the format for feedback *data*
at all? It looks to me that we only need to standardize
some *encapsulation* format for feedback (see Hans' email
http://www.cdt.luth.se/robhc/msg03674.html). Then, the 
following procedure should work (basically, let the 
compressor controls the feedback format.)

(Some notation: A is one endpoint and B is the other. 
compressor-A1 means compressor 1 of endpoint A)

1) compressor-A1 sends to SigComp B the UDVM code that
can generate feedback data when parsing a compressed message.
2) SigComp B: the UDVM generates feedback similarly 
to the creation of state. 
3) if the decompressed message that triggered the feedback
passes security check, the feedback is passed to compressor-B1 
(that talks to SigComp A). Note the role of endpoint ID here.
4) Compressor-B1 piggybacks the feedback with a compressed
message sent to endpoint A. 
5) decompressor-A pass the feedback to compressor-A1.
6) compressor-A1 parse the feedback. It knows the format.

Note in 4), a standalone feedback can be used if endpoint
A has means to verify the feedback message (authentication
and integrity).

BR,
Zhigang

> From: ext Price, Richard [mailto:[email-masked]]
> Sent: April 03, 2002 6:33 AM
> To: 'Hans Hannu (EPL)'; [email-masked]'

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Thu, 4 Apr 2002 13:13:49 +0200

> It looks to me that we only need to standardize
> some *encapsulation* format for feedback 

I think that this is what we're doing now.
What is actually in the requested_feedback "announcement" field and how that data is formatted is up to the compressor to specify by uploading the UDVM code. 

BR
/Hans H