[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] Byte-alignment
I would suggest it's prudent not to bound the
solution space with this constraint, altough
a Byte aligned solution is clearly desirable, if
it can be achieved without wasting radio resources.
alessio
> ----------
> From: Mikael Degermark[SMTP:micke@cs.arizona.edu]
> Sent: 07 April 2000 22:08
> To: Lars-Erik Jonsson
> Cc: rohc; Mikael Degermark; Carsten Bormann
> Subject: Re: [rohc] Byte-alignment
>
> I was planning to say that, yes. It seemed to be the consensus in
> Adelaide.
> Objections, anyone?
>
> Micke
>
> At 02:14 PM 4/7/00 +0200, Lars-Erik Jonsson wrote:
> >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??
> >
> >BR
> >/Lars-Erik
> >
> >
> >
> >
> >
> >>Hi all ROHC-ers!
> >>
> >>Discussion of technical issues on this list is of fundamental importance
> to get
> >>results in the WG. I will therefore start with a discussion about the
> >>byte-alignment issue and I hope we can clear this out easily.
> >>
> >>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.
> >>
> >>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.
> >>
> >>We MUST always have versions of the scheme that are designed
> byte-aligned. A
> >>non-byte-aligned scheme may be instantiated to byte-alignment but will
> not make
> >>use of all bits in an optimal way.
> >>
> >>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.
> >>
> >>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/
>