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

[zhigang.liu@nokia.com]

> -----Original Message-----
> From: EXT Mikael Degermark [mailto:micke@cs.arizona.edu]
> Sent: Thursday, March 30, 2000 7:13 AM
> To: Magnus Hartman
> Cc: zhigang.liu@nokia.com; L.Wood@eim.surrey.ac.uk; rohc@cdt.luth.se
> Subject: RE: [rohc] draft-ace-robust-hc-01.txt
> 
> 
> Hi Magnus, 
> 
> At 02:16 PM 3/30/00 +0200, Magnus Hartman wrote:
> >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).
> 
> Yes, and the bits are cryptographically scrambled so there is 
> no redundancy
> to utilize for compression. 
> 
> >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?
> 
> rfc2507 defines how compress the AH. All fields of the AH 
> except for the actual 
> authentication data can be compressed away. 

Yes, that's true. One thing I'm curious about is that
rfc2507 (section 7.9) doesn't mention the Sequence Number
field in AH. It seems that it can also be compressed since it
monotonically increases (rfc2402, section 2.5). Mikael, maybe
I missed some reason that we should not compress it?

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

Yes, that's right, but only in one aspect. The more important part
is the coding method. ACE uses VLE to encode RTP SN and IP-ID, which
allows just enough bits to be sent according to the field values of 
incoming packets. It does NOT assume any particular packet loss or
misordering condition before the compressor. It does not even assume
the values are increasing or decreasing. This makes VLE a very
good candidate to compress RTP Timestamp in a video stream.

The idea is very simple: DYNAMICALLY increase or decrease number
of bits sent, so that correct decompression is guaranteed while
high compression efficiency is achieved.

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

See above. 

In the case of unidirectional links, there are still some other
information which can be used by the compressor (e.g., maximum
number of consecutive packet loss between compressor and 
decompressor). Of course, with absolutely no feedback channel,
refreshes have to be sent by the compressor.

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