Subject: RE: [rohc] Expressing scaled compression of fields in ROHC-FN.

From: "Finking, Robert" <[email-masked]>
Date: Wed, 4 May 2005 11:03:25 +0100

Hi Kris, All,

I've just thought of a really obvious solution to this that requires no
change at all to the FN, and is really simple. But it must be wrong
otherwise we'd have thought of it before.

Why don't we just use a structure to split out the alternatives, like
this:

seq_num(payload_size) ===
{
   uc_format = seq_number;

   co_format_no_payload =
   {
     let(payload_size == 0);
     let (seq_number_residue:uncomp_value ==
          seq_number:uncomp_value);

     let (seq_number_scaled:uncomp_value == 0);
   };

   co_format_with_payload =
   {
     let(payload_size != 0);
     let(seq_number_residue:uncomp_value ==
         mod(seq_number:uncomp_value, payload_size));
     let(seq_number:uncomp_value ==
        seq_number_scaled:uncomp_value * payload_size +
        seq_number_residue:uncomp_value);
   };
}

Similarly for "ack", and then in the co_baseheader we have:

  control_fields =
  {
    seq_number ::= seq_num(payload);
    ack        ::= ack_num(ack_stride);
  }

Which requires no new syntax, and is scaleable.

Please go ahead and point out the gaping hole in this suggestion, which
must surely exist - it's so obvious that we'd have thought of it before
otherwise!

Comments please - we're almost there now!

Cheers

Raffles

> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]] 
> Sent: Thursday, April 21, 2005 1:58 PM
> To: [email-masked]
> Subject: [rohc] Expressing scaled compression of fields in ROHC-FN.
> 
> 
> Hi all!
> 
> The main obstacle remaining in expressing the TCP packet 
> formats in ROHC-FN 
> seems to be the one related to the scaled sequence and ack 
> numbers (previously 
> discussed on the list a number of times regarding division by 
> zero etc).
> 
> And for a packet with an unscaled sequence number (for 
> example co_format_rnd_1), 
> we would need to have some kind of if-statement so that we 
> can say (because of 
> the zero-division issue):
>     if (payload_size == 0)
>         let (seq_number_residue:uncomp_value == 
> seq_number:uncomp_value);
>         let (seq_number_scaled:uncomp_value == 0);
>     else
>        let (seq_number_residue:uncomp_value ==
>                 mod(seq_number:uncomp_value, payload_size));
>        let (seq_number:uncomp_value ==
>             seq_number_scaled:uncomp_value * payload_size +
>             seq_number_residue:uncomp_value);
> 
> 
> Currently, these expressions are placed in the control_fields 
> of co_baseheader 
> like this:
> 
>     control_fields  =
>     {
>        let (seq_number_scaled:uncomp_value ==
>                 seq_number:uncomp_value / payload_size);
>        let (seq_number_residue:uncomp_value ==
>                 mod(seq_number:uncomp_value, payload_size));
>     };
> 
> But, as anyone can see, the payload of zero will fail to bind 
> for all packet 
> formats with this. So, we thought about having two different 
> control_field 
> definitions like this:
> 
>    control_fields_no_payload =
>    {
>      let(payload_size == 0);
>      let (seq_number_residue:uncomp_value ==
>           seq_number:uncomp_value);
> 
>      let (seq_number_scaled:uncomp_value == 0);
>    };
> 
>    control_fields_with_payload =
>    {
>      let(payload_size != 0);
>      let(seq_number_residue:uncomp_value ==
>          mod(seq_number:uncomp_value, payload_size));
>      let(seq_number:uncomp_value ==
>         seq_number_scaled:uncomp_value * payload_size +
>         seq_number_residue:uncomp_value);
>    };
> 
> But, this approach does NOT scale. Since we have two fields 
> to handle (seq/ack), 
> then we're up to 4 control_fields definitions and one more 
> field takes us to 8, 
> so no, this is not going to scale in a way that makes FN usable.
> 
> Therefore, we need to be able to express if-statements in 
> ROHC-FN. Yes, I know 
> we've had this discussion multiple times before and gotten 
> around it, but we 
> can't just keep patching things when we all the time get back 
> to the fact that 
> if-statements will make this easier! I've discussed this with 
> both Robert and 
> Ghyslain offline, and we got no further than to 
> if-statements. So, the syntax we 
> would like to add is:
> 
> control_fields =
> {
>      let(payload_size == 0)
>      {
>            let (seq_number_residue:uncomp_value == 
> seq_number:uncomp_value);
>            let (seq_number_scaled:uncomp_value == 0);
>      }
>      let(payload_size != 0)
>      {
>            let(seq_number_residue:uncomp_value ==
>                mod(seq_number:uncomp_value, payload_size));
>            let(seq_number:uncomp_value ==
>                seq_number_scaled:uncomp_value * payload_size +
>                seq_number_residue:uncomp_value);
>      }
> 
> }
> 
> So that each let _can_ contain a block-statement and we can 
> bind to one of these 
> . If that wrecks havoc with the FN syntax, We just replace the 
> "conditional let" 
> with "if", which I guess would be reasonably easy to define.
> 
> Feedback, please. With this addition, I think we would be 
> done with the FN draft 
> and the TCP packet formats will be syntactically finished 
> (even if the content 
> can still be discussed).
> 
> BR,
> 	Kristofer Sandlund, Effnet AB
> 
> _______________________________________________
> 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: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Mon, 9 May 2005 13:07:45 +0200

Hi Robert,

it seems like your solution could work, but it looks a bit awkward to me.

The thing is that in the control_fields, we will bind "seq_number ::= seq_num" structure,
but in for example format co_format_rnd_1, we will bind "seq_number ::= lsb". 
For this format, both these bindings need to be performed, but will there be any problem
with FN overriding or cancelling out one of these bindings when both are for the same field?

If the FN itself is fine with this, I can accept this solution for ROHC-TCP.

/Kristofer Sandlund

> From: Finking, Robert [mailto:[email-masked]]
> Sent: den 4 maj 2005 12:03
> To: [email-masked]
> Cc: Kristofer Sandlund (LU/EAB)
> Subject: RE: [rohc] Expressing scaled compression of fields 
> in ROHC-FN.
> 
> 
> Hi Kris, All,
>

---

From: "Finking, Robert" <[email-masked]>
Date: Mon, 9 May 2005 13:54:24 +0100

Hej Kris,

Congratulations on making it through to the other side =) I really
appreciate your response as I know you must have a lot on your plate
with changing location.

Answers inline

Welcome back =)

Regards

Raffles

> From: Kristofer Sandlund (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Monday, May 09, 2005 12:08 PM
> To: Finking, Robert; [email-masked]
I guess the naming looks a bit awkward we might want to call it
"seq_num_scaling" or something like that.

> when both are for the same field?
No, it will be fine. Both bindings will apply, just as they would if
they were done directly in let-statements.

> If the FN itself is fine with this, I can accept this 

Phew! I think we just resolved the last major issue!!