RE: [rohc] draft-ace-robust-hc-01.txt

[khiem.le@nokia.com]

Hi Magnus,

Thanks for your comments. In response to your question about the "adaptive"
in ACE, your understanding is pretty correct, but let me elaborate a bit to
give a more complete picture.
ACE is adaptive at 2 levels: during the course of a session, and at the
algorithm parameterization level.
- During the course of a session, the compressor proactively and constantly
adapts its behavior to avoid loss of synchronization at the decompressor;
for example, it transitions from a lower compression state to a higher
compresssion state only when it knows the decompressor has the information
to decompress the information that would be sent in the higher compression
state; another example of adaptiveness is in the encoding technique of
Variable Length Encoding (VLE); VLE by its very nature is adaptive, because
the compressor determines k, the number of LSBs sent, on a packet by packet
basis, to ensure correct decompression at the decompressor; k is a function
of the current value to be compressed and of previous values in a sliding
window W. The window itself is updated based on feedback received from the
decompressor, or on some estimate of loss if there is no feedback. In
practice, k is chosen as the smallest value in a set, say {k1, k2, k3} that
meets the "correct decompression" criterion.
- At the algorithm parameterization level, there are some parameters in ACE
which can be tuned to a particular environment. Examples of such parameters
are the above mentioned {k1, k2, k3}. Another example is L, the parameter
that determines the size of the VLE sliding window in the case of
unidirectional mode (in this case, the window consists of the last (L+1)
values sent). If the error distribution characteristics are somewhat known
for a particular transmission environment, L corresponds to an estimate of
the maximum number of consecutive packets lost. Note that parameters such as
{k1, k2, k3} require an agreement with the decompressor. Agreement can be
achieved by some profile and/or parameter negotiation mechanism. 

The meaning of "ACE" has been changed from "Ack" to "Adaptive" because we
realized that the essential concepts in ACE are based on the adaptiveness
and proactive behavior of the compressor. Feedback and acknowledgment is a
major and very important case, but not the only one.

Khiem

-----Original Message-----
From: EXT Magnus Hartman [mailto:Magnus.Hartman@northstream.se]
Sent: Thursday, March 30, 2000 6:17 AM
To: zhigang.liu@nokia.com; L.Wood@eim.surrey.ac.uk
Cc: rohc@cdt.luth.se
Subject: RE: [rohc] draft-ace-robust-hc-01.txt


Hi,

Even though this discussion is somewhat old, I have a few comments/questions
on IPsec and ACE and ACE as such. See below.

-----Original Message-----
From: zhigang.liu@nokia.com [mailto:zhigang.liu@nokia.com]
Sent: Tuesday, March 14, 2000 3:38 AM
To: L.Wood@eim.surrey.ac.uk
Cc: rohc@cdt.luth.se
Subject: RE: [rohc] draft-ace-robust-hc-01.txt

>> I was wondering about compressing authentication overhead; some people
>> believe authentication will be used on a hop-by-hop basis to give you
>> IP header checksum functionality in IPv6...
>> > L.
> Hmm, that's interesting. Maybe we could do something here. But again,
> it depends on the hop-by-hop assumption.
>
>Zhigang

I am not an expert on IPsec, but as far as I've understood it, there are 4
"modes": tunneling-ESP, transport-ESP, tunneling-AH and transport-AH?
When it comes to header compression, the ESP is out of the question (except
for compressing the "visible" IP header), since the whole idea is that no
one should be able to manipulate your headers (and payload).

With the AH however, shouldn't it be possible to simply define profiles, in
e.g. the ROCCO framework, for both tunneling and transport mode of AH, where
the AH header have to be sent over the link? Regardless of the hop-by-hop
assumption?
Sure, there are probably more spectrum efficient solutions, but if AH will
be used for different reasons, (e.g. to solve the lack of checksum in IPv6),
then it is motivated?
Have you ROCCO guys looked into this? Or somebody else?

Finally, When browsing through the ACE draft, I realized that 'A' in ACE
stands for 'Adaptive' (first time I heard about ACE the 'A' stood for
'Acknowledged'.). So, what exactly does 'Adaptive' refer to? I suspect that
it is related to the compression states (FH, FO, etc.) and that the
algorithm as such adapts to the situation by means of changing compression
states? Correct?
In any case, could you please elaborate a little bit further on this, e.g.
what exactly is adaptive in the algorithm and what does the algorithm adapt
to, i.e. what kind of information is used for adaptation decisions,
especially in the case of Unidirectional mode?

Regards,

Magnus Hartman
---
Magnus Hartman
Northstream AB
Phone: +46(0)70 6475551
http://www.northstream.se



---
Mailing list for Robust Header Compression WG
Archive: http://www.cdt.luth.se/rohc/