[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [rohc] operating assumptions (section 4.1)

To: khiem.le@nokia.com
Subject: RE: [rohc] operating assumptions (section 4.1)
From: Mikael Degermark <micke@CS.Arizona.EDU>
Date: Sun, 10 Sep 2000 01:21:38 +0200
Cc: micke@optima.CS.Arizona.EDU, rohc@cdt.luth.se
In-Reply-To: <8572CF1E2A95D211A1190008C7EAA2460271FFAD@daeis05nok>

Hi Khiem,

The text in question is the following:

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.

I agree that the wording is too strong. The number 1e-5 for the residual error rate is taken from the ROHC requirements document:

section 2.3 of draft-ietf-rohc-rtp-requirements-02.txt:

"11. Residual errors: For a residual bit-error rate of at most 1e-5,
   the ROHC scheme must not increase the error rate.

   Justification: Some target links have a residual error rate, i.e,
   rate of undetected errors, of this magnitude.

   Note: In the presence of residual bit-errors, ROHC will need error
   detection mechanisms to prevent damage propagation. These mechanisms
   will catch some residual errors, but those not caught might cause
   damage propagation. This requirement states that the reduction of
   the damage rate due to the error detection mechanisms must not be
   less than the increase in error rate due to damage propagation."

....which I agree is not at all the same as saying that the lower layer MUST NOT
deliver a BER of more than 1e-5.

How about the following weasel-wording:

Error detection/protection

The ROHC scheme has been designed to cope with residual errors in the headers delivered to the decompressor. CRCs and sanity checks are used to reduce damage propagation. However, it is RECOMMENDED that lower layers deploy an error detection scheme for ROHC headers and avoid delivering headers with a substantial residual bit error rate.

Without mandating a hard limit on the residual error rate, it is noted that the ROHC requirements state that for a residual bit error rate of at most 1e-5, the ROHC scheme will not increase the number of damaged headers, i.e., the number of damaged headers due to damage propagation will be less than the number of damaged headers caught by the ROHC error detection scheme.

Cheers,

Micke

At 07:03 PM 9/8/00 -0500, khiem.le@nokia.com wrote:
>Hi Micke,
>
>I have not followed very closely the latest discussions on the ROHC mailing
>list, so it could be that I have missed something, but I was wondering where
>does that 1e-5 figure for error rate come from? The last time I saw some
>data related to error rate was in the july 8 mail from Juha, giving some
>answers from TSG RAN WG2 (excerpt below). Based on that mail, I think we
>should set the worst case error rate (the one that lower layer MUST not
>exceed) at 1e-2.
>
>Khiem
>
>------------------ Excerpt from Juha's mail of July 8
>---------------------------------
>
>Moi,
>
>The TSG RAN WG2 (RAN2) discussed the questions presented by ROHC working
>
>group in meeting #14, 3 - 7 July, Paris, France. The answers that RAN2 come
>
>up are presented below after each copied question.
>
>Q1: What range of residual bit error rate can be expected in compressed
>
>RTP/UDP/IP headers? What is the residual bit error rate of a worst case were
>
>error detection is provided but with the smallest possible link layer
>
>checksum?
>
>Lower layer of the UMTS are flexible and they can be configured by
>
>several different ways. E.g. CRC length can be 0, 8, 12, 16 or 24 bits.
>
>Furthermore, the RAN typically deals with the block error rate instead of
>
>residual BER. However, RAN2 assume that real time traffic could be run over
>
>a radio bearer which would produce residual BER in the range of 10-2 to
>
>10-6. The RTP/UDP/IP header compression algorithm produced by ROHC should be
>
>capable of operating in different conditions providing different residual
>
>BER.
>
>----------------------------------------------------------------------------
>----------
>
>Khiem
>
>-----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/ <http://www.cdt.luth.se/rohc/>
>> --- Mailing list for Robust Header Compression WG Archive:
>http://www.cdt.luth.se/rohc/
>

References:
- RE: [rohc] operating assumptions (section 4.1)
  - From: khiem.le@nokia.com

Prev by Date: RE: [rohc] operating assumptions (section 4.1)
Next by Date: RE: [rohc] operating assumptions (section 4.1)
Prev by thread: RE: [rohc] operating assumptions (section 4.1)
Next by thread: RE: [rohc] operating assumptions (section 4.1)
Index(es):
- Date
- Thread