Subject: [rohc] Clarifications for the Implementer's guide

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Thu, 30 May 2002 13:56:46 +0200

Hi all,

During Arctic ROHC, some questions were raised that the group of people
present thought should be clarified in the Implementer's guide. Apart from
questions about the list compression parts, I noted two issues that we
agreed should be clarified. I'll briefly explain the issues, and make
initial text proposals:

1) How to respond to lost feedback links?
One question that was raised was whether a feedback link is assumed to
always be available if once present, or if the feedback link could
disappear, and in such case what to do about it. People agreed that this
is link dependent, and not really a ROHC protocol issue. If this can
happen over a certain link technology, the issue should be handled for
each such case. If this can happen, the compressor should be able to handle it, and a natural solution would be to restart with a new 
context. It should be noted that a restart in this case would mean a
new context is created.

Proposed text for implementer's guide:

  X.Y.  How to respond to lost feedback links

     One potential issue that might have to be considered, depending on 
     link technology, is whether feedback links might get lost, and in 
     such cases how this is handled. If this can happen, the compressor
     should be made capable of handling it, e.g. by restarting compression
     with a new context. Generally, feedback links are not expected to
     disappear when once present, but it should be noted that this might
     be the case for certain link technologies.

2) What does "presumed zero if absent" mean on page 88?
On page 88, the RFP header flags and fields are listed and explained. For
the RTP Padding, the following is said:
"R-P: RTP Padding bit, absolute value (presumed zero if present)."

The question was whether this meant:
a) Absent from Extension
b) Absent from the whole ROHC packet
c) Absent from the RTP header flags and fields

The Arctic ROHC participants agreed that c) seemed to be the reasonable
assumption, which could be noted in chapter 4 of the Implementer's guide.

Cheers,
/L-E

-----------------------------------
Lars-Erik Jonsson, M.Sc
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research and Experiments
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Peter Kremer (ETH)" <[email-masked]>
Date: Thu, 30 May 2002 14:49:32 +0200

Hi,

According to my notes I have a third issue, which is about the id of CSRC lists.

There can be an extension-3 in UO-1-ID packets with a compressed CSRC list in "RTP header flags and fields". CSRC list uses encoding type 0 (section 5.8.6.1, page 120) and every list could have an id, which is present if a compressor wants to use this list as a future reference.

The problem is that the compressor intends to use this list in the future but the context isn't updated (because it's a UO-1 packet).

So what should a decompressor do if it receives such a packet (UO-1-ID, ext-3, CSRC list with gen_id)? Should it save the list because the compressor may use it in the future or should it forget it after the decompression of the current packet because the context isn't updated?

Abbey, did I missed something?

-- 
Peter Kremer, MBA                  Tel: +36-1-437-7033
Ericsson Hungary Ltd.              Fax: +36-1-437-7767
Conformance Center ETH/RL/S        Mobile: +36-30-311-2118
http://conformancelab.ericsson.se  E-mail: [email-masked]

---

From: "Peter Kremer (ETH)" <[email-masked]>
Date: Thu, 30 May 2002 15:32:03 +0200

Hi,

> 1) How to respond to lost feedback links?
I think the guide should be a bit more specific and maybe it would be safe to mention that a new context implies a new CID...

"One potential issue that might have to be considered, depending on link technology, is whether feedback links might get lost, and in such cases how this is handled. When the compressor is notified that the feedback channel is down, the compressor must be able to handle it by restarting compression with creating a new context. Creating a new context also implies to use a new CID value.

Generally, feedback links are not expected to disappear when once present, but it should be noted that this might be the case for certain link technologies."

> assumption, which could be noted in chapter 4 of the 

My proposed text is:

"4.X.  What does "presumed zero if absent" mean on page 88?

On page 88, RFC 3095 says that R-P contains the absolute value of RTP Padding bit and it's presumed zero if absent.  It could be absent from RTP header flags and fields, from the extension type 3 or from the ROHC packet. It's been agreed that the first case is the most probable."