[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rohc] FN: default_methods and control fields clarification/new usage

inline.

Finking, Robert wrote: 
Hi Kris,

Thanks for the response. I had a quick look at the formats before my
post and there didn't seem to be a problem, since although they do use
such definitions in default_methods, they never get overridden, or else
they're overridden correctly. However I missed "sack_var_length_enc"
when I was skimming through. You're right it needs fixing, but this
needs fixing anyway, since there is currently no control fields list. To
recap any field which does NOT appear in the uncompressed header, but
that DOES have an uncompressed side, needs to be declared in a control
fields list.


Disagree. See below.

This is not a big deal though, it just means replacing the
current "default_methods" line with "control_fields", so you end up with
this:

        control_fields = sack_offset   %[ 32 ]
        {
                let (sack_offset:uncomp_value ==
                     sack_field:uncomp_value - base);
                let (sack_offset:uncomp_length == 32);
                let (sack_field:uncomp_length == 32);
        };


Hmm... I think we again have some kind of disconnect regarding the control fields. As far as I remember, it was me and Ghyslain who pushed for the control fields, and our intention was that these should be "fields that are kept in context between packets", while our intention was not to have define control fields that are just using during the processing of a single packet. And this is what the WG decided in Washington, but maybe this got lost on the way to the draft. I get the feeling that you define control fields differently than that (again, I have not checked FN for some time, but I though it contained what we had decided earlier).
I think this is quite an important distinction that we should keep since it helps implementers a lot to know what is actual context that is used next time and which are just used for the "current packet".

If we use "my" definition, then we cannot define sack_offset as a control_field and we need another solution.

Similarly with seq_number_scaled etc. in baseheaders - they need
declaring in a control_fields list anyway. Hopefully it's a just a quick
cut and paste?

These are already defined as control fields on the global level (see the start of the file).


Note this does NOT affect fields which have no uncompressed side at all,
such as compressed side CRCs or the many flags which are used.

Agreed, but as I try to describe above, what _you_ call control_fields are in _my_ mind two different categories where only one can be defined as a control_field.

BR,
	Kristofer


Thanks for keeping an eagle eye out =)

Raffles

-----Original Message-----
From: Kristofer Sandlund [mailto:kristofer.sandlund at effnet.com] Sent: Friday, April 15, 2005 3:55 PM
To: Finking, Robert
Cc: rohc at ietf.org
Subject: Re: [rohc] FN: default_methods and control fields clarification/new usage


Hi Robert,

actually, this _does_ affect the current TCP packet formats (e.g. sack_var_length_enc and co_baseheader), since we have used a number of let-statements on control fields inside default_methods (at least I think these are identical cases to what you're describing).

My understanding when I made the packet formats was that you always "executed" the default methods and then if new encoding for a field was present in the compressed formats, you "overwrote" the default_methods encoding. But obviously, this is not what you meant (but I haven't read the actual text in the FN for a long time).
I think the change you propose looks reasonable, but I'm not yet sure how this will work for the TCP packet formats, so I'd have to think this though a bit more. Could you check the tcp packet formats and see how your change maps to the current formats (the examples I listed above)?

BR,
	Kristofer Sandlund, Effnet AB



Finking, Robert wrote:

All,

Whilst doing the latest lot of updates, I've found an error

in the current FN draft. It is to do with the way default_methods are used. To recap, default_methods are referred to if and only if there is no encoding given for a field in a packet format. If an encoding is given for that field then there is no need to refer to the default: it is just a fall back to use when no other encoding is specified.

In the Appendix B (which I'm currently editing) we have the 

following in an example:

 control_fields = scaled_seq_no;

 default_methods       =
 {
   version_no          ::=   uncompressed_value(2,1);
   type                ::=   irregular(2);
   flow_id             ::=   static;
   reserved_flag       ::=   uncompressed_value(1,0);

   % need modulo maths to calculate scaling correctly,
   % due to 4 bit wrap around
   let(scaled_seq_no:uncomp_value
         == ((mod(15 - sequence_no:uncomp_value, 3) * 16
              + sequence_no:uncomp_value) / 3));
   scaled_seq_no       ::=   lsb(1,-1);
 };

The problem here is that the default_methods specifies not

only the *default* encoding for the field (lsb), but also the binding for the uncompressed value of the field. The default encoding isn't referred to when a packet format specifies an encoding of its own - that fine. The binding for the uncompressed value however should ALWAYS be referred to, since this is what gives the control field its value. Since this binding is in default_methods, it will not always be referred to =(

The way the FN draft is currently written, the solution to

this problem is to move the essential bit of code (the "let" statement) into the uc_format encodings list. However, this is not a cure-all since sometimes there will be multiple uc_formats.

The intuitive solution is to put the binding for the

uncompressed value of the control field under the control_fields list. Apart from clarifying an issue which is currently not nailed down in the draft (whether or not a field encodings list can be specified for control_fields), it actually reads really nicely:

 control_fields = scaled_seq_no   %[ 4 ]
 {
   % need modulo maths to calculate scaling correctly,
   % due to 4 bit wrap around
   let(scaled_seq_no:uncomp_value
         == ((mod(15 - sequence_no:uncomp_value, 3) * 16
              + sequence_no:uncomp_value) / 3));
 };

 default_methods       =
 {
   version_no          ::=   uncompressed_value(2,1);
   type                ::=   irregular(2);
   flow_id             ::=   static;
   reserved_flag       ::=   uncompressed_value(1,0);
   scaled_seq_no       ::=   lsb(1,-1);
 };

As an aside, since this is really just a clarification it 

shouldn't affect the current packet formats as far as I can see.

I thought I'd better post this in case there were any

objections - it strikes me this could be viewed as more than just an editing issue!

Regards

Raffles

_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc