RE: [rohc] Byte-alignment

[zhigang.liu@nokia.com]

> -----Original Message-----
> From: EXT Lars-Erik Jonsson [mailto:lars-erik.jonsson@ericsson.com]
> Sent: Friday, April 07, 2000 7:15 AM
> To: rohc
> Cc: Mikael Degermark; Carsten Bormann
> Subject: Re: [rohc] Byte-alignment
> 
> 
> Some days ago, I sent this question to the list. Since there 
> have been no
> arguments against the opinions I raised in this issue, I 
> would like to make a
> request to put this into the requirements document. Even if 
> it is obvious to me
> that the scheme should be byte-aligned, I know that it is not 
> clear to all of
> those involved in this. Therefore the requirements document 
> must state that only
> byte-aligned solutions should be considered.
> 
> Micke, will you include that in some way??

Wait a second. In the original email, which was sent exactly
two days ago, there was nothing about requirements document.
Correct me if I'm wrong, you raised byte-alignment as an 
issue "when discussing solutions".

Now that you made a request to put byte-alignment into
the requirements, I would like to make some comments
(see below) though I agree with most of your points.

Furthermore, it would be nice if we allow "some days" for
people to comment on this request. A general discussion
of byte-alignment is a different thing from adding
it into requirements document. Of course, one can always
comments when Mikael makes the final call on the draft,
which is probably coming pretty soon.

> 
> BR
> /Lars-Erik
> 
> 
......
> >The question is whether there is any reason to design a robust header
> >compression framework that can support non-byte-aligned versions of the
scheme.
> >I do not think so. All link-layers I have seen are byte-aligned and that
is also
> >preferrable from an implementation point of view.

I agree with you that most existing link-layers are probably
byte-aligned. However, it is mostly because of tradition
and computation cost (as you pointed out) consideration.
There is nothing to prevent L2 using start-stop flags (e.g. HDLC)
to carry non-byte-aligned data.

I guess this is actually an issue of the interface between link
layer and upper layer.

Also note that L2 in wireless environment could be non-byte-aligned
in the future. We already know there are many differences between
wired link and wireless link (because of L1). What I mean is that
most existing L2s are for wired link, where it makes no sense to
support sub-octet payload. Exiting L2s on radio link were designed
with the assumption of circuit-like channel to carry constant bit
rate traffic. IP (and packet data in general) was not there.

> >
> >This question is important because the answer gives 
> different approaches to the
> >problem.
> >1) When designing a non-byte-aligned scheme, the objective 
> is to make all
> fields
> >as small as possible on a bit-level.
> >2) For byte-aligned schemes the objective is instead to 
> squeeze as much
> >information as possible into 1, 2 or several bytes. Then the 
> smallest possible
> >header size must always be used.

Agree. But I would rather view this as an issue of granularity.
The goal is still the same: achieve the smallest average header size.
Byte-alignment is just an additional constraint of the problem.

> >
> >We MUST always have versions of the scheme that are designed 
> byte-aligned. 

Totally agree. A good use of "MUST". 

Note that, however, this statement does NOT say non-byte-aligned
versions MUST NOT be considered. We should be careful to
before making such a strong conclusion.

> >A non-byte-aligned scheme may be instantiated to 
> byte-alignment but will not make
> >use of all bits in an optimal way.

I'm not sure about that. Again, it's a matter of granularity.
It's true that a naive instantiation MAY lose the efficiency
(in term of average compressed header size), if we compare
byte-aligned and non-byte-aligned versions of the SAME scheme.

However, I don't see any reason why a scheme cannot make
efficient use of the extra bits during the instantiation.
It all depends on how you use them, right?

> >
> >I think it is important to clarify that (and if) we are only 
> considering
> >byte-aligned solutions. Some mechanisms for non-byte-aligned 
> solutions will not
> >be usable at all in a byte-aligned scheme and we could then 
> ignore such
> >mechanisms when discussing solutions.

First of all, we definitely need to come up with a byte-aligned
solution FAST. However, I am not convinced that we MUST ONLY 
consider byte-aligned solutions. At least, we should keep the
door open for "future link technologies", as stated in the 
ROHC charter.

Second, if some mechanisms are proven useless for byte-aligned
schemes, they should certainly be ignored when discussing
BYTE-ALIGNED solutions. 

I can see a mechanism could be less efficient in byte-aligned 
header format than in non-byte-aligned one. However, I don't 
see why they will not be usable at all, or necessarily less 
efficient that another mechanism that is only applicable to
byte-aligned header format. Any examples in mind?

In summary, I think byte-alignment is an issue of compressed
header format and the interface to link layer. It's a constraint
rather than a requirement. We probably need to focus on 
byte-aligned solution in the coming few months. However, we 
should not preclude non-byte-aligned solutions from ROHC task
list, at least not before we're convinced to do so.

BR,
Zhigang

> >
> >Regards!
> >/Lars-Erik
> >
> >
> >--------------------------------------------------------------
> >Lars-Erik Jonsson, M.Sc. - Ericsson Research
> >AWARE - Advanced Wireless Algorithm Research at Erisoft
> >Box 920, S-971 28 Luleå, Sweden
> >E-mail: lars-erik.jonsson@ericsson.com
> >Phone: +46 920 20 21 07
> >Mobile: +46 70 554 82 71
> >Fax: +46 920 20 20 99
> >Home: +46 920 999 57
> >
> >
> >---
> >Mailing list for Robust Header Compression WG
> >Archive: http://www.cdt.luth.se/rohc/
> 
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
>