Subject: RE: [rohc] ROHC compression ratio

From: Remi Pelland <[email-masked]>
Date: Wed, 30 Jul 2003 17:38:50 -0400

Hi Abbie and Alan,

I found the following message sent by Lars-Erik which discusses the changes
he intended to do to the implementer's guide, just before version 03 was
released.  Point #3 discusses the empty generic CSRC list.  Based on his
comments, it seems like the generic CSRC list field must not be included
when the list is empty.  

http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01308.html

However, this only applies to the CSRC list and not to the IP extension
header lists.

Salut,
Remi.

-----Original Message-----
From: Remi Pelland [mailto:[email-masked]]
Sent: Wednesday, July 30, 2003 2:00 PM
To: 'Surtees, Abigail'
Cc: ROHC mailing list
Subject: RE: [rohc] ROHC compression ratio

Abbie,

I agree with you that for IP extension headers, the generic extension header
list must always be present, empty or not, otherwise it would be impossible
to properly parse the packet.  The second paragraph of section 4.3.1 in the
implementer's guide says that exactly.

However, my understanding of the beginning of section 4.3.3 is that the
meaning of the generic CSRC list field is modified with respect to what is
defined in the RFC.

In my understanding, sections 4.3.1 and 4.3.3 do create a difference between
the generic extension header list and the generic CSRC list in the
particular case where these lists are empty: for IP extension header, 1 or 2
bytes are present, while for CSRC list no byte is present (presence being
established based on the CC field of the first byte of the RTP dynamic
chain).

Thanks,
Remi.

-----Original Message-----
From: Surtees, Abigail [mailto:[email-masked]]
Sent: Wednesday, July 30, 2003 12:52 PM
To: 'Remi Pelland'; 'Alan Kennington'
Cc: ROHC mailing list
Subject: RE: [rohc] ROHC compression ratio

Hi Alan, Remi,

Answering two mails in one:

There have been 4 rohc interop tests July 2001, Nov 2001, April 2002 and Oct
2002.  We attended the first 3 but not the 4th so I may have missed
something there.  However, I think that the byte of zero has to be present
otherwise the IR packet cannot be decompressed correctly for the following
reason.  
(If I'm wrong and/or there was something I missed at the 4th interop then I
hope someone will correct me...)

Both CRSC lists and generic extension header lists are encoded according to
list compression in section 5.8.

When the decompressor reads the dynamic chain it reads the parts of the IP
header.  When it reads the next byte how does it know whether it is the
first byte of generic extension header list or it is the first byte of UDP
checksum?  
Surely it must read a byte of header list that indicates the list is empty
according to 5.8.6 and then go on to read the UDP checksum?

This follows through then to the CSRC list (even though the CC field in the
dynamic chain can indicate that the CSRC list will be empty).

Having the byte there allows generic list processing to look at the header
in the appropriate place.  If this were not the case then there would have
to be extra logic (which I believe is not in the RFC) to say check the
protocol field to find out if there is a generic IP extension header list
present and check the CC field to find out if the CSRC list is present.

Consequently I think the byte should be present.

I hope this makes sense.

Regards,

Abbie

Abbie Surtees
Engineer
Networks
Roke Manor Research Ltd
Tel:   +44 (0) 1794 833131

>
>Well, now I'm a bit confused.  Originally, my implementation 
>added the empty
>CSRC list byte - as stated in RFC 3095, section 5.7.7.6, but I 
>removed it
>after reading the implementer's guide.
>
>I understand that interoperability tests were done with the 
>empty CSRC list
>byte present, but the implementer's guide says otherwise in 
>section 4.3.3(
>(...)It should be noted that when the value of this CC field 
>is equal to
>zero, there is no Generic CSRC list present in the dynamic 
>chain, i.e. the
>field comment should have said "variable length, present if CC 
>> 0" (...) ).
>I guess because it was very specific to that field, I must 
>have taken that
>sentence as a special case for the CSRC list.  
>
>Now, I don't mind putting the empty byte back, buy I want to 
>be sure I'm
>doing the right thing.  So I ask: what is the proper way to 
>handle empty
>CSRC lists?  Peter, Lars-Erik any thoughts?
>
>Thanks,
>Rémi.
>

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

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

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

---

From: Vicknesan Ayadurai <[email-masked]>
Date: Thu, 31 Jul 2003 09:30:31 +0200 (CEST)

Hi Remi/Abbie/Alan,

Thought I'd join in the fray with my "2-octets" worth here...

Specific to the CC/Generic CSRC list discussion, we did do some basic
CSRC-list compression testing at the 4th interop in Berlin last year.

At that point, a CC-value of 0 (in the IRDYN dynamic chain) would
still result in a 1-octet Generic CSRC List. In fact, there have been
implementations which would produce a 2-octet Generic CSRC list (when
said CC-value was 0), since a Generic CSRC list would be produced and
subsequently assigned a (1-octet) gen_id as well.

I believe I'm partially responsible for the text by Lars-Erik in the
link below (forwarded by Remi), since I brought this issue up after
the interop event.

I also believe the intention now is to interpret a CC-value of 0 as NO
Generic CSRC list present, but perhaps that can be confirmed/verified
by someone else...

Regards,
vick
+----------------------------------------------------+
 Vicknesan AYADURAI <[email-masked]>
 SwitchLab, Ericsson Research - Stockholm, Sweden
 Phone :  +46 8 5087 8084 / Fax:  +46 8 5087 8090
+----------------------------------------------------+

---

From: Tommy Lundemo <[email-masked]>
Date: Thu, 31 Jul 2003 10:12:25 +0200

Hi Vick/Remi/Abbie/Alan/all!

I just wanted to give you my opinion on this.
The extra (CC=0, generic CSRC list=0) octet needs to be there according to 
the standard (variable length, not optional field in 5.7.7.6), even though 
I agree that for future updates it should not be
necessary.

The point is that we are trying to get interoperable
implementations, then I think we cannot allow the Implementers
Guide to override things in the current standard, but only
advise on how to implement the present standard and possibly
make suggestions on how to improve it in the future.

Best Regards

/ Tommy Lundemo, Effnet AB