[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,
Again, thanks. I think the real issue here is the default methods! I can
understand what you mean about the control_fields, but you have to ask
yourself what that means formally. In order to be able to refer back to
the previous header in the flow, you need to have context and that means
you need to have an uncompressed part.
I don't think there's an easy way to define whether you use the context
or not. The FN just doesn't work like that. Therefore the FN draft
merely requires that you declare a context i.e. an uncompressed side.
Does that make sense?
Raffles
> -----Original Message-----
> From: Kristofer Sandlund [mailto:kristofer.sandlund at effnet.com]
> Sent: Friday, April 15, 2005 4:20 PM
> To: Finking, Robert
> Cc: rohc at ietf.org
> Subject: 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