RE: [rohc] operating assumptions (section 4.1)

[zhigang.liu@nokia.com]

Hi Mikael,

Just one comment on the terminology "error protection". It seems
to me that what we really mean is "error detection", i.e. the
ability to detect an transmission error. "error protection"
means to protect a packet (or frame) against transmission error
(e.g. using some coding to add redundancy). Of course, that's only my 
interpretation. But either way, I suggest we clarify it in the terminology 
section. 

I also heard people have different interpretation of "residual bit error". 
It may help adding it to the terminology section too. Suggested text:
residual bit error - the undetected transmission bit error.

Br,
Zhigang


-----Original Message-----
From: EXT Mikael Degermark [mailto:micke@CS.Arizona.EDU]
Sent: Friday, September 08, 2000 12:41 PM
To: zhigang.liu@nokia.com
Cc: rohc@cdt.luth.se
Subject: Re: [rohc] operating assumptions (section 4.1)


Zhigang & others, 

I am going over the document right now, and have changed section 4.6 into
the 
following. I'll attempt a merge with 4.1.

Micke

4.6.  Requirements on lower layers

This chapter lists general ROHC requirements on an underlying link layer.
See also the ROHC lower layer requirements document [LLG].

Framing

The link layer MUST provide framing, which makes it possible to distinguish
individual frames. 

Length 

The link layer MUST indicate the length of frames to the decompressor. There
is no length information in compressed packet headers. 

Error protection 

The ROHC scheme has been designed to cope with residual errors in the
headers delivered to the decompressor. However, the lower layer MUST NOT
deliver a residual bit error rate larger than 1e-5. 

It is RECOMMENDED that at least the header part of frames are protected
using strong checksums. The error protection SHOULD ensure that packets with
errors in the header part are never delivered. 

Negotiation 

In addition to the packet handling mechanisms above, the link layer MUST
provide a way to negotiate header compression parameters. 


At 09:52 AM 9/8/00 -0500, zhigang.liu@nokia.com wrote:

>Hello Folks,
>
>In the current rohc draft (ver 01), there are two sections that seem
>to be redundant to each other: 4.1. Operating assumptions and 
>4.6. Requirements on lower layers.
>
>I guess it's probably an unintentional result of on-going editorial 
>work when we merged different proposals, as the case for many other 
>sections. Since lower layer guideline will address the issues in a 
>separate draft, I'd like to suggest that we keep the section 4.1 
>"operating assumptions" and remove section 4.6.
>
>I list at the end of this email some assumptions that are at least 
>needed for rohc protocol. Please give comments on whether they are 
>sufficient, so that we can finalize this section.
>
>I'm also working on the 4.5 encoding methods (merging texts addressing
>the same issue, adding some text e.g. offset IP-ID encoding, etc). It
>will probably be ready next Monday. 
>
>Br,
>Zhigang
>
>------------------------------------------------------------------
>
>4.1.  Operating assumptions
>
>packet length: the link layer can provide the length of a compressed
packet.
>
>(it is beneficial but not required to provide the length of a feedback
>packet)
>
>error detection: the link layer can provide reasonably good error detection

>for compressed headers and feedback packets. (Error protection is 
>beneficial but not required.)
>
>in order delivery: the link layer between the compressor and decompressor 
>preserves the order of packets being transmitted, i.e. the decompressor 
>(compressor) will receives the packets in the order they were sent by the 
>compressor (decompressor). (Note that packet misordering before compressor
>can be handled by rohc protocol)
>---
>Mailing list for Robust Header Compression WG
>Archive: http://www.cdt.luth.se/rohc/
>