Subject: RE: [rohc] ROHC compression ratio

From: Remi Pelland <[email-masked]>
Date: Wed, 30 Jul 2003 11:12:58 -0400

Hi Abbie,

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.

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

Hi Alan, Remi,

I remember we had problems with this at the first interop (hence there being
a section about it in the implementer's guide).  In my understanding and our
implementation; for both the CSRC list (and also for the IP extension header
list), there is one byte of zero in the dynamic chain if the list is empty.

Here is the trace of an IR packet from our implementation (showing the 1
byte lists with ^^^^):
 0: FD 01 57 40 11 00 00 00 00 00 00 00 00 33 73 8F : ý.W@.........3s.
16: 59 15 64 96 E0 E0 26 30 EE 20 00 00 00 90 35 C0 : Y.d.àà&0î ....5À
                                 ^^^^
32: 45 5F CA 6A 56 00 04 00 01 02 03 04 05 06 07 50 : E_ÊjV..........P
                  ^^^^
48: 4B 54 3A 20 20 20 31                            : KT:   1

where the original packet is:
 0: 45 E0 00 38 30 EE 00 00 26 11 62 E8 00 00 00 00 : Eà.80î..&.bè....
16: 00 00 00 00 33 73 8F 59 00 24 00 00 80 35 C0 45 : ....3s.Y.$...5ÀE
32: 5F CA 6A 56 15 64 96 E0 00 01 02 03 04 05 06 07 : _ÊjV.d.à........
48: 50 4B 54 3A 20 20 20 31                         : PKT:   1

Alan, I think you are right that the implementer's guide appears to be
contradictory and I believe that implementations that have been interop
tested follow 4.3.1 and 4.3.2.  

Regards,

Abbie

>-----Original Message-----
>From: Alan Kennington [mailto:[email-masked]]
>Sent: 30 July 2003 15:29
>To: Remi Pelland
>Cc: ROHC mailing list; Alan Kennington
>Subject: Re: [rohc] ROHC compression ratio
>
>
>On Wed, Jul 30, 2003 at 09:41:52AM -0400, Remi Pelland wrote:
>> 
>> the RTP part of the dynamic context an empty Generic CSRC 
>List is present
>> although the associated CC field is 0.  Section 4.3.3 of the 
>Implementer's
>> Guide says that when the CC field is 0, the Generic CSRC List is not
>> included in the dynamic chain.
>> 
>
>
>Remi,
>
>Well, that's delightful. That's the first time anyone's checked the
>correctness of my encoding.
>
>Now the ROHC implementer's guide, version 3, part 4.3.1, says
>
>===================================================
>   The generic extension header list starts with an octet that 
>is always
>   present, so its length is one octet, at least.  If the 'GP' bit in
>   the first octet is set to 1 then the length of the list is two
>   octets, even if the list is empty.
>===================================================
>
>Then section 4.3.2 says:
>
>===================================================
>   Section 5.7.7.6 defines the static and dynamic parts of the RTP
>   header.  This section indicates a 'Generic CSRC list' field in the
>   dynamic chain, which has a variable length.  This field 
>uses the same
>   encoding rules as the 'Generic extension header list' in the IPv4
>   header, so the same rules apply to its length.
>===================================================
>
>This seems pretty clear to me - the CSRC list must have at 
>least 1 octet
>even if CC equals 0.
>
>Hmmm. Then this is contradicted in 4.3.3 of the implementer's guide:
>
>===================================================
>   Section 5.7.7.6 defines the static and dynamic parts of the RTP
>   header.  In the dynamic part, a 'CC' field indicates the number of
>   CSRC items present in the 'Generic CSRC list'. 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". A 'CC'
>   field can also be found within the 'Generic CSRC list' (when
>   present), and these fields would then have the same 
>meaning. In order
>   to decode a compressed packet correctly it's necessary to know the
>   'CC' value because it has serious impact on the packet's length.  In
>   normal case, the values of the fields are equal.
>
>   Proposed behavior if the values are different:
>      Both fields are within the RTP dynamic part but only the second
>      'CC' field resides inside the 'Generic CSRC list' together with
>      the XI items.  Since the 'CC' value determines the number of XI
>      items in the CSRC list and isn't used otherwise, the first CC
>      field should be ignored and only the second field 
>(inside the CSRC
>      list) should be used for incoming packets.  For outgoing packets
>      both fields should be set to the same value.
>===================================================
>
>So this means that if CC == 0, then the CSRC list is not present.
>This is very confusing. It seems to me that even the "clarifications"
>in the Implementer's guide might be contradictory.
>
>So what is the real answer?
>
>Salut aussi,
>Alan Kennington.
>
>--------------------------------------------------------------------
>     nom: Dr. Alan Kennington
> website: http://www.topology.org/
>   ville: Adelaide, Australie Me'ridionale
>  coords: 138.59 E, 34.88 S
>zone UTC: +0930 http://www.topology.org/site/timezone.html
>clef-pgp: http://www.topology.org/ak/key_ak2.asc
>    note: Mon adresse de courriel se change souvent a` cause du spam.
>        : Si votre courriel bounce, visiter SVP 
>topology.org/extra/email.php
>
>_______________________________________________
>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: Remi Pelland <[email-masked]>
Date: Wed, 30 Jul 2003 12:09:05 -0400

Hi Abbie,

I was just wondering: the interop tests you were mentionning, were they done
before or after publication of version 03 of the implementer's guide?

I was just thinking that if the interop was done before this particular
publication, perhaps the intent was to remove the empty CSRC list byte (to
improve compression, I guess) even though the prior tests were made with the
empty CSRC list byte present.

I noticed that the sentence saying that "the Generic CSRC List should not be
present when CC=0" was not in the implementer's guide before version 03
(February 28, 2003).  

So I'm thinking that this may have been added after the interop tests you
were talking about.

Just trying to figure this out...

Thanks,
Remi.

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

Hi Abbie,

Thanks,
Rémi.

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

Hi Alan, Remi,

Regards,

Abbie

---

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 30 Jul 2003 17:51:34 +0100

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

>field comment should have said "variable length, present if CC 
>> 0" (...) ).

---

From: Remi Pelland <[email-masked]>
Date: Wed, 30 Jul 2003 14:00:08 -0400

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,

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.

I hope this makes sense.

Regards,

Abbie

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 31 Jul 2003 14:36:42 +0100

Hi Tommy, Vick, Remi, Alan, all,

Thanks for your opinion Tommy.  I agree with you - the Implementer's Guide
should clarify things that are ambiguous in the RFC (e.g. how to calculate
the CRC) but should not change things that are clear.  If it did it would
mean that an implementation that does what is specified in the RFC cannot
interoperate with one that follows what is in the implementer's guide, which
would not be a good state of affairs.

If there are changes like this to be made, then they should be made when the
RFC progresses to draft standard.  If the implementer's guide is also a log
of things that need changing then they should be clearly marked or,
preferably, put in a separate section e.g. an appendix.

Regards,

Abbie

>
>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
>
>On Thu, 31 Jul 2003 09:30:31 +0200 (CEST), Vicknesan Ayadurai 
><[email-masked]> wrote:
>
>> 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: Remi Pelland <[email-masked]>
Date: Thu, 31 Jul 2003 09:32:27 -0400

Everyone, 

Abbie and Tommy make a good point and I agree with it.  But now that the
implementer's guide is out there and says what it says at the beginning of
4.3.3, how should this be handled?

Is there a concensus that the empty CSRC list should be represented by 1 or
2 bytes?  If so, the implementer's guide should probably be modified.

Regards,
Remi.

-----Original Message-----
From: Surtees, Abigail [mailto:[email-masked]]
Sent: Thursday, July 31, 2003 9:37 AM
To: 'Tommy Lundemo'; Vicknesan Ayadurai; Remi Pelland
Cc: 'Alan Kennington'; ROHC mailing list
Subject: RE: [rohc] ROHC compression ratio

Regards,

Abbie

---

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 31 Jul 2003 15:16:52 +0100

Hi Remi, all,
>4.3.3, how should this be handled?
Good question ... anyone?

>2 bytes?  If so, the implementer's guide should probably be modified.
Are you referring here to section 4.3.1 of the Implementer's guide?  I think this section is clear and that it is an implementation decision whether the GP bit is set or not (and consequently whether the empty CSRC list is represented by 1 or 2 bytes) so there is no need to change this section of the guide.

Regards,

Abbie

---

From: Remi Pelland <[email-masked]>
Date: Thu, 31 Jul 2003 10:10:14 -0400

Abbie,

I was not particularly referring to 4.3.1 - it's fine the way it is.  

All I was trying to ask is if there was a concensus that when the CSRC list
is empty, that the encoding to be used is the one defined in the RFC, as
opposed to what is stated at the beginning of sectioin 4.3.3 of the
implementer's guide (i.e. your implementation vs mine :-) ).  That's all...

Thanks,
Remi.

-----Original Message-----
From: Surtees, Abigail [mailto:[email-masked]]
Sent: Thursday, July 31, 2003 10:17 AM
To: 'Remi Pelland'; 'Tommy Lundemo'; Vicknesan Ayadurai
Cc: 'Alan Kennington'; ROHC mailing list
Subject: RE: [rohc] ROHC compression ratio

Hi Remi, all,

>2 bytes?  If so, the implementer's guide should probably be modified.
Are you referring here to section 4.3.1 of the Implementer's guide?  I think
this section is clear and that it is an implementation decision whether the
GP bit is set or not (and consequently whether the empty CSRC list is
represented by 1 or 2 bytes) so there is no need to change this section of
the guide.

Regards,

Abbie

---

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 31 Jul 2003 15:43:37 +0100

Hi Remi, Alan,

I misinterpreted your question.  Thanks for the clarifications.

Regards,

Abbie