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

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

Hi Robert,

comments inline.

Finking, Robert wrote: 
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 disagree. If we take the example with sack_offset, that field does not refer to any field in a previous header, it is just a field calculated from another field in the same header. It has an uncompressed side, but clearly, it does not have context.
Therefore, this field cannot be a control_field as per how the WG discussed them in Washington (and I haven't seen any discussion that we have updated that decision). With your proposal, this would have to be defined as a control field.
Btw, the minutes from the meeting is not really clear on which interpretation to use, so I can understand if you interpreted it differently.


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.


I think it seems quite easy to define that, if you take the current text:

   The control fields list specifies all fields that do not appear in the
   uncompressed header but which have an uncompressed value
   (specifically those with a non-zero uncomp_length).

and add something like:
   and the value of the field is persistent between packets (i.e. have context).

After all, the only thing such a definition does is to narrow down where the profile creator is allowed to define control fields and not. You do not have to define what "have context" means, right?
If we don't add that kind of text, this is something that is going to cause both possible profile writers and even more profile users to start asking question regarding which fields are to be stored in context and I'd like to avoid having to have a "FN user's guide".


Does that make sense? 

Unfortunately, no :)

BR,
	Kristofer Sandlund, Effnet AB




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


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