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

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 21 Apr 2005 15:33:51 +0200

Kristoffer,

I rethought about this. The issue is not about having a conditional, but rather an issue on scoping. I think the "let" statement that "fails" the entire scope of the packet format is needed and shouldn't be changed. What you are after is to assert one part of the scope of a packet format without "failing" the entire format.

I suggest instead that we allow the use of a scoping operater, e.g. the braces "{" and "}" that we already use could be used to add one scoping level to englobe the let as a conditional that does not fail the entire scope of the packet format.

Thoughts?

/Ghyslain 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Kristofer Sandlund
> Sent: den 21 april 2005 14:58
> To: [email-masked]
> Subject: [rohc] Expressing scaaled 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 regarind 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-divison 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 havc 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 <[email-masked]>
Date: Thu, 21 Apr 2005 15:43:02 +0200

Hej!

If I understand you correctly you suggest syntax like:

co_format_example
{
     {
        let(value == 0)
        blah ::= static;
     }
     {
        let(value != 0)
        blah ::= irregular;
     }
}

If so, that seems to work.
I'd _like_ for it to be more explicit on when things are mutually exclusive and 
when both can match, since more complex conditions will probably be easy to mess 
up for the profile writer. But it's not a "show stopper", so I can accept 
whichever of these two most people like.

/Kristofer