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

[zhigang.liu@nokia.com]

> -----Original Message-----
> From: EXT Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk]
> Sent: Monday, March 13, 2000 6:07 PM
> To: zhigang.liu@nokia.com
> Cc: rohc@cdt.luth.se
> Subject: RE: [rohc] draft-ace-robust-hc-01.txt
> 
> 
> On Mon, 13 Mar 2000 zhigang.liu@nokia.com wrote:

> > > 4.2 - 'Error detection is beneficial, but optional'; I can see
> > >       this becoming a MUST as far as headers are concerned...
> > 
> > No. It states "Error CORRECTION is beneficial, ...". 
> > 
> > It is certainly a MUST to have error detection.
> 
> mea culpa. It will still be a MUST to correct header errors IMhO.

Actually, by error correction, we mean link layer error correction.
(e.g., some forward error correction scheme, channel coding, etc).
It's a tradeoff. You add more bits (redundancy) so that you can
achieve higher percentage of surviving compressed headers.

ACE, as other HC schemes, only assumes that the link layer is able
to detect a transmission error in a compressed header, and throw it 
away. That's all it needs. ACE can tolerate pretty severe and 
fluctuating loss of compressed headers and still decompress correctly
(i.e., reconstruct correct headers). 

If you mean error correction on the compressed headers at link layer,
I would partially agree with you, in the sense that it reduces the
packet loss rate (what we mean by beneficial). But, it's a tradeoff
(you pay for it). It's more close to an implementation issue and 
depends the actual link characteristics (e.g., BER) and the size of 
compressed headers ... 

> 
> > > Ordered flow requirement is implicit, rather than 
> explicitly stated.
> > 
> > What do you mena? Ordered flow before compressor, or between 
> > compressor and decompressor? ACE can handle adaptively the 
> > misordering before compressor. It can also handle the latter 
> > case with the cost of efficiency.
> 
> Efficiency cost? I couldn't find that bit. (There's a mention in
> 2.2.3: affect not effect there) I missed 4.1, which is the explicit
> ordering statement I was looking for. ACE is assuming that it's
> working across an ordered link, yes?

Yes, the current ACE assumes an ordered link, for simplicity. But, as
the draft also states (4.1) that this assumption can be relaxed in
future version. What do you pay? Some extra overhead (but small). There
is no free lunch :-). 

What we are trying to do is to give the basic and clear ideas. Once
they're understood, we can add things to make ACE more powerful.

> 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

> 
> <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
> 
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
>