gmane.ietf.rohc

Query regarding the LSB encoding in TCP Profile

Clark Peng (彭冠仁 — 2013-05-23T02:07:34

Hi all,

Please clarify me about the inconsistency LSB encoding description in seq_7, rnd_1 and rnd_8.

In RFC 6846, page 43, under TCP Sequence Number, it specifies offset_param p = 2^(k-1)-1.”
In RFC 6846, page 44, under TCP Acknowledgment Number, it specifies offset_param p = 2^(k-2)-1.”

However, in the formal notation Section 8.2 in RFC 6846,

1.      For seq_7, ack_number    =:= lsb(16, 32767)   =>   2^(16-2)-1=16383 != 32767

2.      For rnd_1, seq_number    =:= lsb(18, 65535)   =>   2^(18-1)-1=131071 != 65535

3.      For rnd_8, seq_number    =:= lsb(16, 65535)   =>   2^(16-1)-1=32767 != 65535

I’ve read the email discussion about this and the conclusion seems to align the formal notation in 8.2.

Nevertheless, if we inspect the seq_number in rnd_8,
seq_number    =:= lsb(16, 65535).

The notation specifies the interpretation interval for seq_number is 2^16=65536 with offset_param=65535.
To my understanding, it means seq_number is NEVER interpreted as increasing!!
Is this d

Re: FYI: ROHC-TCP update => RFC6846

Didier Barvaux — 2013-04-28T19:15:34

Kristofer,


I took some time to answer you, but I would like to thank you for the
update. It helped me a lot with SACK options 2 months ago!

There was a problem when the ROHC implementation I maintain was
(de)compressing them. Implementing the updated RFC fixed the problem :)

Regards,
Didier

FYI: ROHC-TCP update => RFC6846

Kristofer Sandlund — 2013-02-15T09:39:46

Just FYI for anyone still reading this list, the ROHC-TCP update was published last month, 
obsoleting RFC4996. Hopefully, we managed to iron out the bugs that were left.

https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=11613&tid=1360920357 

http://www.rfc-editor.org/rfc/rfc6846.txt

BR,
   Kristofer

rfc5225 msn_lsb improvement

Klaus Warnke — 2012-09-04T10:56:03

Hello everybody,

I think, the msn_lsb() encoding method could be improved:

msn_lsb(k)
{
...
   COMPRESSED none {
     ENFORCE(reorder_ratio.UVALUE == REORDERING_NONE);
     master =:= lsb(k, 1);
   }
...
}

For reorder ratio REORDERING_NONE the
     master =:= lsb(k, -1);

is sufficient. That is, offset_param = -1,
If there is no reordering, there is no need to have a lower bound -1 
before the ref_value.
If the msn increase by +1, the lower bound could be ref_value +1.

See also rfc3095:

    a) For field values that are expected always to increase, p can be
       set to -1.  The interpretation interval becomes
       [v_ref + 1, v_ref + 2^k].


Any comments?

Regards,
Klaus

RFC5225 IP-ID with co_common and Random behavior and tos_tcchanges

Klaus Warnke — 2012-09-04T10:48:14

Hello everybody,

if the ip-id has a random behavior, it is sent in the irregular chain
as defined in ipv4() encoding method and ipv4_innermost_irregular format.
This encoding method has a DEFAULT section, which also defines that
tos_tc is encoded static (and other).
If I understand den ROHC FN right, the format
ipv4_innermost_irregular could not be used,
if the tos_tc could not encoded by the static encoding method.
But then I can not use co_common format to transmit tos_tc changes,
because the ip_id is not included in co_common if the behavior is random.
Is this correct?

Regards,
Klaus

Re: RFC4996bis

Wesley Eddy — 2012-09-04T04:03:29

We haven't seen any responses to this query.  This is a reminder nudge
in case people have been on vacation, or otherwise slow to respond.
Currently, this question is the only thing holding the 4996bis document
up, so feedback would be appreciated!


On 8/18/2012 11:32 PM, Wesley Eddy wrote:

[Editorial Errata Reported] RFC5857 (3320)

RFC Errata System — 2012-08-16T08:01:44

The following errata report has been submitted for RFC5857,
"IKEv2 Extensions to Support Robust Header Compression over IPsec".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5857&eid=3320

--------------------------------------
Type: Editorial
Reported by: Nikolai Malykh <nmalykh< at >gmail.com>

Section: 3.1.2

Original Text
-------------
   This section describes five ROHC Attribute Types: MAX_CID,
   ROHC_PROFILE, ROHC_INTEG, ROHC_ICV_LEN, and MRRU.  The value
   allocated for each ROHC Attribute Type is specified in Section 4.


Corrected Text
--------------
   This section describes five ROHC Attribute Types: MAX_CID,
   ROHC_PROFILE, ROHC_INTEG, ROHC_ICV_LEN, and MRRU.  The value
   allocated for each ROHC Attribute Type is specified in Section 5.


Notes
-----
Section 4 of RFC 5857 is "Security Considerations". Values of ROHC Attribute Types listed in Section 5.

Instructions:
-------------
This errata is currently posted as

RFC4996bis

Wesley Eddy — 2012-08-19T03:32:54

As you may be aware, the authors of RFC 4996 have been working
on an update that's currently held up in the IESG Review based
on the following DISCUSS comment from Russ:

"""
  The issue below is the same as the one raised in the Gen-ART Review
  by Joel Halpern on 16-July-2012.

  Section 5.2.2.2 on negative acknowledgments includes the following:
  >
  > ... unless it has confidence that information sent after the packet
  > being acknowledged already provides a suitable response ...
  >
  This deals with a specific response to the NACK, it is unclear what
  constitutes confidence.  Other places in this document that refer to
  gaining confidence provide specific descriptions of how it is gained.
  The primary methods for gaining confidence are receiving acks or
  sufficient transmissions.  If all that is meant here is sufficient
  transmissions, please say so.
"""

There seems to be disagreement about whether additional text
would be useful in this regard.

We'd like to hear from people on this ROHC maili

Re: [Technical Errata Reported] RFC5225 (3248)

Carl Knutsson — 2012-07-31T06:21:55

It looks correct to me too.

/Calle

On 07/29/2012 01:08 AM, Wesley Eddy wrote:

Re: [Technical Errata Reported] RFC5225 (3248)

RoHC Team — 2012-07-29T09:08:21

  Hello,

  Thank you for your post.

  Best regards,

              FWX.

Le 29/07/2012 01:08, Wesley Eddy a écrit :

Re: [Technical Errata Reported] RFC5225 (3248)

Wesley Eddy — 2012-07-28T23:08:57

This errata looks correct to me; if nobody objects, I'll mark it
as "Verified" in the errata tool later this week.


On 6/7/2012 10:14 AM, RFC Errata System wrote:

[Technical Errata Reported] RFC5225 (3248)

RFC Errata System — 2012-06-07T14:14:50

The following errata report has been submitted for RFC5225,
"RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5225&eid=3248

--------------------------------------
Type: Technical
Reported by: FWX <rohc_team< at >dialine.fr>

Section: 6.8.2.4

Original Text
-------------
page 67:

  COMPRESSED udp_lite_endpoint_dynamic {
    ENFORCE(profile_value == PROFILE_UDPLITE_0108);
    reserved =:= compressed_value(4, 0)                      [  4 ];
    coverage_behavior =:= irregular(2)                       [  2 ];
    reorder_ratio     =:= irregular(2)                       [  2 ];
    checksum_coverage =:=
      checksum_coverage_dynchain(coverage_behavior.UVALUE)   [ 16 ];
    checksum          =:= irregular(16)                      [ 16 ];
    msn               =:= irregular(16)                      [ 16 ];
  }

page 68:

  COMPRESSED udp_lite_regu

Statefull SIGCOMP

kishore sowdi — 2012-06-06T12:02:45

Hi,
 
I am using SIGCOMP to compress/decompress SIP application messages.

SIP Client is uploading UVDM bytecode in all messages it sends to server (Not stateful).

Message flow:
1) SIP REGISTER from Client to Server
2) 200 OK response from Server to Client for (1).

3) SIP SUBSCRIBE Client to server
4) 200 OK response from Server to Client for (3).

At (2). , SIP Client is stores the state after decompressing 200 OK response.
 (Pasting the packet sniffer(wireshark) logs .. ... shows 3 state create requests in "UDVM Execution Trace")

[-]UDVM execution trace
 no_of_state_create 3
 ### Creating state ###
 Partial state identifier: AEDBAB80652A
 ### Creating state ###
 Partial state identifier: AAA2B32CE212
 ### Creating state ###
 Partial state identifier: 
 
what does partial id signify here during state create ??...

Now, At (4),  Server references the state by giving partial state identifier. (please see below trace pasted)
But, this referred state identifier and state identifier of stored s

Re: Question regarding SIGCOMP

kishore sowdi — 2012-05-29T10:11:15

Hi List,
 
One more observation this issue:
 
After decompressing message (4).. 200 OK For REGISTER, SIP Client creates state having state identifier (SHA1 result) and stores it.
 
But at (6).. 200 OK to SUBSCRIBE, Server references a partial state identifier, which does not match with state identifier which is generated as mentioned above.
 
Should they match ? .
 
At (4), Server asks to create state using Partial Id, what does partial id signify here during state create ??
[-]UDVM execution trace
 no_of_state_create 3
 ### Creating state ###
 Partial state identifier: AEDBAB80652A
 ### Creating state ###
 Partial state identifier: AAA2B32CE212
 ### Creating state ###
 Partial state identifier: 
 Please help in identifying the issue...
 
Regards,
Kishore

From: kishore sowdi <kishore_r_s< at >yahoo.co.in>
To: Carsten Bormann <cabo< at >tzi.org> 
Cc: "rohc< at >ietf.org" <rohc< at >ietf.org> 
Sent: Wednesday, 23 May 2012 2:20 PM
Subject: Re: [rohc] Question regarding SIGCOMP


Hi Carsten,
 
With reference to

Re: Question regarding SIGCOMP

kishore sowdi — 2012-05-23T08:50:00

Hi Carsten,
 
With reference to my earlier diagram, I am describing state create and state access made by server.
 
In message (4), I see 3 state creates made by server
[-]UDVM execution trace
 no_of_state_create 3
 ### Creating state ###
 Partial state identifier: AEDBAB80652A
 ### Creating state ###
 Partial state identifier: AAA2B32CE212
 ### Creating state ###
 Partial state identifier: 
 
 In message (6), I see state access(referenced) using partial state id made by server.
 [-]Signaling Compression
  Returned_feedback item: 03
  Partial state identifier: AEDBAB80652A
  Remaining SigComp message bytes: 280
  ### Accessing state ###
  Partial state identifier: AEDBAB80652A
 
In message (4), 
- I can see 3 state creates as part of "UDVM Execution trace" as decipted by Wireshark (Network Protocol Analyzer) .
- Why did not server send these three state create requests using STATE-CREATE as part of UDVM byte code?
 
In message (6),
- State having AEDBAB80652A id is referenced (state acc

Re: Question regarding SIGCOMP

Carsten Bormann — 2012-05-23T08:15:04

Kishore,

your diagram does not really show the important parts:

Question regarding SIGCOMP

kishore sowdi — 2012-05-23T06:16:15

Hi ,

I am using SIGCOMP to compress/decompress SIP application.

SIP Client is uploading UVDM bytecode in all messages it sends to server.
Below is the message exchange between SIP Client and Server,
 

Client                                                                                 Server
1) REG (Client sends bytecode) ---->

                                                                                      (2) <----  401(Server sends byte code)                                            
 
3) REG  (Client sends bytecode) ---->    
 
                                                                                      (4) <----- 200 OK (Server sends byte code)  

5) SUBSCRIBE (Client sends b

rfc5225 RoHCv2 ipv4_outer_irregular format question

Klaus Warnke — 2012-04-13T14:57:14

Hello

In the encoding method ipv4() in the format ipv4_outer_irregular{}:

   COMPRESSED ipv4_outer_irregular {
     ENFORCE(is_innermost == 0);
     ip_id    =:=
       ip_id_enc_irreg(ip_id_behavior_outer.UVALUE)      [ 0, 16 ];
     tos_tc   =:= static_or_irreg(outer_ip_flag, 8)      [ 0, 8 ];
     ttl_hopl =:= static_or_irreg(outer_ip_flag, 8)      [ 0, 8 ];
   }

I could not determine how the value of the IP-ID in case of
ip_id_behavior_outer is either IP_ID_BEHAVIOR_SEQUENTIAL or
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED is computed.

The encoding method ip_id_enc_irreg() is used to handle the IP-ID here.
But for the IP-ID behavior cases stated above I can not figure out,
how it is computed.

Did I oversee something?

Maybe the line
     ip_id         =:= inferred_sequential_ip_id       [ 0 ];
is absent here?

But it could not be, because the English text definition talks
about ip_id_behavior_innermost.

ip_id_enc_irreg(behavior)
{
   UNCOMPRESSED {
     ip_id [ 16 ];
   }

   COMPRESSED ip_id_seq {
     ENFO

RoHCv2 ipv4_innermost_irregular question

Klaus Warnke — 2012-04-12T16:13:29

Hello!

I could not determine, where the attribute

    ip_id_behavior_innermost.UVALUE

is bound in this format (ipv4 encoding method):

   COMPRESSED ipv4_innermost_irregular {
     ENFORCE(is_innermost == 1);
     ip_id =:=
       ip_id_enc_irreg(ip_id_behavior_innermost.UVALUE)  [ 0, 16 ];
   }

In the  ipv4_outer_irregular format the ip id behavior is defined in 
DEFAULT as static.
I understand here, that the irregular chain (and therefore CO formats)
could not be used, if the ip-id behavior of an outer IP header has changed.
Then I need a co_repair/IR with dynamic chain.

But if the innermost ip id behavior changes, I can use co_common.
Then the ip id is either send within co_common (in seq/seq swapped case)
or within irregular chain (in rand/zero) case.

Therefore maybe the line
     ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
is missed here, to bind the attribute with the parameter value?

If not, could please someone explain, where the binding works?

Thanks and Regards,
Klaus

Re: [Editorial Errata Reported] RFC5225 (3185)

Carsten Bormann — 2012-04-11T12:20:06


Indeed.  To corroborate (grepping for rtp_version):

rfc5225.txt:3570:    rtp_version =:= uncompressed_value(2, 0) [  2 ];
rfc5225.txt:4354:    rtp_version =:= uncompressed_value(2, 2)           [  2 ];
rfc5225.txt:4391:    rtp_version    =:= uncompressed_value(2, 2)        [   2 ];
rfc5225.txt:5137:    rtp_version    =:= uncompressed_value(2, 2)        [  2 ];
rfc5225.txt:5173:    rtp_version =:= uncompressed_value(2, 2)           [   2 ];

Very clearly, line 3570 is the odd one out here and needs to be fixed, as RTP Version 0 is neither defined nor in use.

rohc_team: 
Thanks for finding this!
(If I still were rohc WG chair, I would ask you for your common name at this point, as it is customary to use wallet names on IETF lists.)

Grüße, Carsten

Re: [Editorial Errata Reported] RFC5225 (3185)

RoHC Team — 2012-04-11T10:48:47

  Hi Christopher,

  Thank you for your quick reply.
  Best regards,

               FWX.

Le 11/04/2012 11:57, Kristofer Sandlund a écrit :