headers
Jer-ming Lin | 4 Sep 2010 08:17
Picon

how to choose the compressed format for RFC3095 IP extension's SN

Dear rohcers,

    In RFC 3095 5.8.5.1, I can not figure how to decide the format of
compressed XX Sequence Numbers out. Or it just compares with the old
XX SNs in the window. If all have same 25 MSBs with the new SN, it is
the 0. In the other hand, if all have same 1 MSBs, it is the 1 format.
Is that right?

Best regards,
Jer-ming Lin
Permalink | Reply | 0 comments |
headers
Sasha Koruga | 15 Sep 2010 23:52

3-bit CRC and IPv6 ip_id_behavior

Dear ROHC enthusiasts,

I have a question concerning section 6.6.11, “control_crc3_encoding” of RFC 5225, particularly for
the RTP profile.  The statement of interest: “ip_id_behavior, one octet for each IP header in the
compressible  header chain starting from the outermost header.”
 
For the RTP profile, are the ipv6 ip_id_behaviors included in the crc3 coverage? We are having an internal
team debate on the issue, and thus I seek your guidance. 
 
I would personally argue “no”, because at section 6.6.11, ip_id_behavior for the ipv6 header is
considered non-existent. Thus, I believe that, although not explicitly stated, the crc3 encoding only
includes one octet for each IPv4 header. 
Only later in the text, in the lower layers (section 6.8.2.4), does an ipv6 ip_id_behavior occasionally
get defined as RANDOM, but I don't believe that subsequently definitions makes that variable into a
control field. 
Furthermore, in the RTP profile section, it states:
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
Thus it only defines one ip_id_behavior_innermost, and not an ip_id_behavior for each IPv6 header, as
would be necessary for a control_crc3_encoding that would encode every ipv6 header, and as it did in the
UDP profile:
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
I believe the purpose of the RTP definition was to allow functions such as ip_id_sequential_variable()
and profile_1_7_flags1_enc() to be used regardless of ipv4 or ipv6, but not to expand the 
control_crc3_encoding() process. 
 
Logically, I also don't think it makes sense to compute the CRC3 of ipv6 ip_id_behavior. The purpose of CRC3
is to ensure that our control variables are in sync. However,  ipv6 ip_id_behavior is always defined as
RANDOM, so it can never be out-of-sync anyway. Adding it to the CRC3 calculation would be an unnecessary
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carl Knutsson | 16 Sep 2010 10:34
Favicon

Re: 3-bit CRC and IPv6 ip_id_behavior

Sasha Koruga,

There are no ipid_behavior control field for outer IPv6 headers. So they
hardly can be added to the control crc.

Section 6.6.11 is very clear, the ip_id_behavior should be added for
every IP header. I don't remember if the intention was to include IPv6
ip_id_behavior or not. However it is clear that something is broken.

I agree with you, it makes no sense adding the inner ipid_behavior and
outer ipid_behavior for IPv6 to the control_crc. These field (if
existing) are not sent as-is in any of the packet formats and are pretty
much protected by the crc-validation/verification. There is no need for
extra protection as in the ip-id case since the decompression will fail
if anything else than RANDOM is sent for IPv6.

Given the text in section 6.6.11, it is not really clear how to handle
this.

I would like to change the text in 6.6.11 to say
"for each IPv4 header" instead of "for each IP header"

I will discuss this with the authors and the AD (I am no longer
responsible for the WG) and file an errata if necessary.

/Calle

On 09/15/2010 11:52 PM, Sasha Koruga wrote:
> Dear ROHC enthusiasts,
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jer-ming Lin | 1 Oct 2010 10:34
Picon

TS encoding for RFC 3095

Hi ROHCers,

  I have a questions about compressing TS(unscaled and scaled). Would
you please give me your advice and clarify me.

1) Does compressor use the transmitted unscaled TS to be its TS
reference when compressing scaled TS at the step 2 of RFC 4815's
4.4.3. Or compressor needs to re-construct the reference of scaled TS.

Thanks in advance,
Jer-ming Lin

2010/2/4 Jer-ming Lin <cs202050 <at> csie.ncu.edu.tw>:
> Dear Sir,
>
> Quoting Carl Knutsson <carl.knutsson <at> effnet.com>:
>>>
>>> ..
>>> TS_STRIDE and the relationship of delta_TS. Is that right?
>>
>> No, the compressor must first establish the TS_STRIDE by sending it
>> as-is together with unscaled TS. From those two values, TS_SCALED and
>> TS_OFFSET can be derived and used for later for compression.
>>
>
>   After establishing the TS_STRIDE and TS_OFFSET, the compressor sends
> scaled TS bits or no TS bits if scaled TS has the relationship of
> "delta_TS=delta_SN*default-slope(TS)."
>
>   For performance issue, if the scaled TS(derived from unscaled
(Continue reading)

Permalink | Reply | 0 comments |

Gmane