[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] FN: default_methods and control fields clarification/new usage
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. 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);
};
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?
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.
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