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 4:31 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:
> 
> > Please find the Internet Draft of "Adaptive Header
> > ComprEssion (ACE) for Real-Time Multimedia" at the
> > URL: http://38.197.106.103/draft-ace-robust-hc-01.txt.
> > 
> > Any comment is welcome.
> 
> (Table) The UDP checksum is non-essential? not in IPv6, surely?
> end of section 2 seems fine on this.

Maybe the word "non-essential" is not the right word. What we
mean is that it cannot be compressed like those "essential"
fields. If it's not optional, it has to be sent uncompressed.
Of course, if one is willing to loose the end-to-end checksum,
forgive me to say that :-), other approach is possible (e.g., 
stronger Link layer CRC may make the relatively weak checksum
redundant).

I noticed your email on the pilc stating that UDP checksum is
no longer optional in IPv6. 

I guess the CRC/Checksum at different layers always trigger
discussions (as in pilc). From the header compression point
of view, the design of the error detection at upper layer 
(UDP, etc) and the link layer should be done together.
I.e., removing redundancy to maximum efficiency. But this may
violate a little bit the layered design philosophy. 

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

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

> Trivial at this stage, but... There are no security considerations
> given.
> 
> L.
> 
> Anyone want to come up with a header compression scheme
> that works well with IPSec?

Good, but difficult question. Basically, you can only compress
a header that is clear (i.e. un-encrypted).

Thanks for comments, Lloyd. I feel there are
some related topics between the work of rohc
the one of pilc. I hope I have time to follow
the materials generated at pilc.

Zhigang

> 
> > BR,
> > Zhigang
> > 
> > ------------------------------------------------------
> > Zhigang Liu                   
> > Research Engineer         |  Phone:  (972) 894-5935
> > Nokia Research Center     |  Fax:    (972) 894-4589
> > Irving, Texas 
> > USA
> > -------------------------------------------------------
> > ---
> > Mailing list for Robust Header Compression WG
> > Archive: http://www.cdt.luth.se/rohc/
> 
> <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
>