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

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 20 Apr 2005 11:59:50 +0200

Hi kristoffer,

>   So, instead I'll just point towards what is actually in the 
>   ROHC-TCP draft right now.

In general, I don't think that the fact that some text already exists is a motivation to move on with a specific solution. As you've mainly work with the packet formats (which provide one interpretation of the Washington agreement) and I mainly worked on the text in FN than it is of no surprise that these contradicts. At least we agree on this. On the other end, I don't think that reviews of the packet formats focused on that part at all so I would not understand this as representing any agreement.

> For that reason, as well as the lack of _clear_ 
> documentation for what we had consensus on, it
> is not only valid, but important to re-open the
> discussion.

I am certainly in favor of discussing this and clarifying this.
That's why I have proposed a simple definition that I hope was clear enough.

> clearly, the fields that _I_ refer to as
> control_fields need to be treated differently 
> than "simple flags" in the PROFILE.

I don't know that we have consensus on this "clearly".

I actually agree that in the implementation, they will be treated differently, but I firmly believe that it is not of the FN to define such difference. The FN specifies packet formats formally, e.g. how to compress each field based on coding methods and assertive statements to generate the butts on the wire, but I believe it is of the scope of the profile definition to define where and how the context information required to choose and generate the actual packets.

So, I'd rather say that for the FN to fullfil its goals there is no need to handle the two types that you defined in a different ways. In terms of properties, controls fields (including what you call simple flags) are no different than uncompressed fields, also as uncompressed fields can be used themselves as simple flags and as control fields may be compressed themselves and be sent in the compressed header.

As a sideline, and this is maybe why Lars-Erik and myself couldnot agree regarding the "overloading" of the "let" statement in a previous discussion, it clarifies I believe that a let cannot be used to define a field, but can be used to bind the value of a field attribute or can be used as a simple assertive statement.

> this separation. If the FN provides this separation, it still 
> does NOT mean that it messes with "context updating" or other
> concepts, it is just a separation of fields to provide
> readability and consistency.

I don't really get you here. I am not talking about context updating, I am talking about properties related to their persistency in the context, what you previously referred to as "fields" with requirements on the context.

Further, I think that this messes up much more than it helps, because the requirements that a field as with respect to the context is in large part related to coding methods and/or the presence of information onto which it depends within the uncompressed header. That is, you'd introduce rules as to that a field used as a flag cannot be the left-hand side of an assignment that has state, such as a binding to a stateful coding method or a binding to an expression that requires state to be kept.

I believe that the definition that I have provided is much cleaner (and clearer for that matter) as all fields not part of the uncompressed header are treated the same manner, only that those that you'd like to use as flags would have some attributes being undefined (which is ok by FN) as long as you don't use these attributes in expression (would lead to an undefined result, which is not allowed).

I'd welcome also more input in this discussion as I feel that, with the distinction that has been proposed, we are stepping over the scope of the FN into the scope of the profiles. And that I want to avoid.

/Ghyslain

> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: den 20 april 2005 11:30
> To: Ghyslain Pelletier (LU/EAB)
> Cc: Finking, Robert; Carsten Bormann; [email-masked]
> Subject: Re: [rohc] FN: default_methods and control fields
> clarification/new usage
> 
> 
> Hi Ghyslain,
> 
> predictably, I'm not in agreement with you. Resoning follows:
> 
> First of all, I have a very different opinion on what the 
> consensus in 
> Washington was. I just read the slides and the minutes from 
> the meeting, but 
> from that I cannot read it one way or the other.
>   So, instead I'll just point towards what is actually in the 
> ROHC-TCP draft 
> right now. The nottion that control_fields were meant to 
> include "all fields not 
> in the uncompressed header" is not supported by section 6.3 
> (tcp-09), which 
> lists the actual control fields that "have context", which is 
> tha same 
> separartionas in the packet formats in the draft. I know that 
> the FN text 
> contradicts this, but it seems like we simply did not know 
> what we had consensus 
> on. For that reason, as well as the lack of _clear_ 
> documentation for what we 
> had consensus on, it is not only valid, but important to 
> re-open the discussion.
> 
> Like I said to you offline yesterday, to me it is important 
> that the TCP spec 
> becomes as readable as possible to the implementer and that 
> the text and packet 
> format definitions are consistent with each other. And 
> clearly, the fields that 
> _I_ refer to as control_fields need to be treated differently 
> than "simple 
> flags" in the PROFILE. And the packet formats included in the 
> rohc-tcp draft 
> _are_ a part of the profile, and therefore should separate 
> the same way as the 
> text. Therefore, the FN needs to provide provisions for "FN 
> code" to provide 
> this separation. If the FN provides this separation, it still 
> does NOT mean that 
> it messes with "context updating" or other concepts, it is 
> just a separation of 
> fields to provide readability and consistency.
> 
> So, I guess we need input on this from more people to be able 
> to resolve things, 
> so please jump in even if you're not in agreement with me :)
> 
> BR,
> 	Kristofer Sandlund, Effnet AB
> 
> 
> 
> Ghyslain Pelletier (LU/EAB) wrote:
> > Hi all,
> > 
> > Sorry or the slow turnaround time to answer on this matter.
> > 
> > Unfortunately, I do not agree.
> > 
> > I _thought_ that we agreed in Washington that control 
> fields have the exact same properties as uncompressed fields 
> (that is, they can have attributes, can be compressed, and 
> must be defined within a scope) but that they would be used 
> to defined any field that is not part of the uncompressed header.
> > 
> > For me, persistency in the context is not something that is 
> related to the formal notation. This is something that is up 
> to the profile to state when defining what controls fields 
> are used and what they are for. Pushing this further, I think 
> that it is just as innapropriate to define a requirement 
> related to context and persistency in the context for control 
> fields as it would be to do this for other fields.
> > 
> > The problem that I see is that a declaration using "let" 
> does not have anything to do about if the field would have a 
> "lifetime" longer than compressing one single packet or a 
> longer lifetime. For example, would let create a binding from 
> a control field to a mathematical expression then the 
> lifetime of the control field is per-packet, would the 
> binding be using a coding method that requires the 
> maintenance of a value in the context than suddenly it would 
> become a "context-requiring" field.
> > 
> > 
> >>>>>>I see three kind of fields, original fields, per-packet 
> >>>>>>created fields,
> >>>>>>and context-requiring created fields (control-fields).
> > 
> > 
> > I cannot see that this distinction is useful for formally 
> notating and parsing of packet formats, which is the 
> objective of the FN. Context requirements is outside the 
> scope of the FN and we have strived as much as possible so 
> far to avoid making such distinction in the notation. Someone 
> explains me why this is suddenly needed for the FN.
> > 
> > In short, I do not agree with the latest proposal.
> > 
> > I propose that control fields be defined as follow:
> > 
> > There are three types of fields: uncompressed fields, 
> control fields and compressed fields. Control fields share 
> the exact same properties as uncompressed fields in that they 
> can have attributes, they can be compressed, and must be 
> defined within their useful scope. The difference from 
> uncompressed fields is that they are not part of the 
> uncompressed header but rather created to help in the 
> compression of uncompressed fields, and may be sent as part 
> of the compressed header in packet formats. Just like other 
> fields, profile may have to specify in some way how their 
> value is maintain in the compressor and decompressor context 
> (this is based on the usage of the control field - e.g. if 
> it's definition and usage depends only of uncompressed values 
> that are always present in the uncompressed header, or if the 
> field can sometimes be compressed and sent along in the 
> compressed header).
> > 
> > I.e. this also means that the :uncomp attribute of control 
> fields _may_ be undefined, as long as this attribute is not 
> used explicitly within the definition of packet formats (the 
> use of undefined value is undefined) and as long as the 
> control field is not compressed.
> > 
> > Since I cannot really grasp exactly why this discussion led 
> to this proposal, I might be somewhat off the problem, but I 
> feel that the above summarizes the consensus that we had in 
> Washington and I see no need to revisit that consensus 
> without making a change that is not right.
> > 
> > Best regards,
> > 
> > /Ghyslain
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>Finking, Robert
> >>Sent: den 19 april 2005 15:09
> >>To: 'Carsten Bormann'
> >>Cc: [email-masked]
> >>Subject: RE: [rohc] FN: default_methods and control fields
> >>clarification/new usage
> >>
> >>
> >>Great, is that consensus? Carsten? Eilert?
> >>
> >>Cheers
> >>
> >>Raffles
> >>
> >>
> >>>-----Original Message-----
> >>>From: Lars-Erik Jonsson (LU/EAB) 
> >>>[mailto:[email-masked]] 
> >>>Sent: Tuesday, April 19, 2005 2:02 PM
> >>>To: Kristofer Sandlund; Finking, Robert
> >>>Cc: [email-masked]
> >>>Subject: RE: [rohc] FN: default_methods and control fields 
> >>>clarification/n ew usage
> >>>
> >>>
> >>>Excellent that you managed to come up with a resolution. To 
> >>>me this sounds fine!
> >>>
> >>>/L-E
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Kristofer Sandlund [mailto:[email-masked]]
> >>>>Sent: den 19 april 2005 13:41
> >>>>To: Finking, Robert
> >>>>Cc: Lars-Erik Jonsson (LU/EAB); [email-masked]
> >>>>Subject: Re: [rohc] FN: default_methods and control fields
> >>>>clarification/n ew usage
> >>>>
> >>>>
> >>>>Robert,
> >>>>
> >>>>I think you covered what we discussed, but maybe we should 
> >>>>also say that a 
> >>>>reason for having the derived_fields definition is so that we 
> >>>>_can_ declare 
> >>>>these in a global scope to help with the accesses between 
> >>>>structures. We don't 
> >>>>believe that this will be used for the TCP profile, but we 
> >>>>don't want to rule it 
> >>>>out of the FN.
> >>>>
> >>>>BR,
> >>>>	Kristofer
> >>>>
> >>>>Finking, Robert wrote:
> >>>>
> >>>>>Hi L-E, All,
> >>>>>
> >>>>>I've just had a phone call with Kris to clarify a few 
> >>>>
> >>>>things from a TCP profile point of view, but OK yes I 
> >>>>basically agree to your suggestion. Comments in-line below to 
> >>>>include the clarifications from the phone call - Kris please 
> >>>>feel free to add anything I've forgotten (which I must have done).
> >>>>
> >>>>>Regards
> >>>>>
> >>>>>Raffles
> >>>>>
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: Lars-Erik Jonsson (LU/EAB)
> >>>>>>
> >>>>>>To me it looks really useful to make this distinction. 
> >>>
> >>>Fields that 
> >>>
> >>>>>>are "created" and used only on a per-packet basis do not 
> >>>
> >>>require an
> >>>
> >>>>>>explicit control-field declaration, but would be declared 
> >>>
> >>>as part of
> >>>
> >>>>>>the compressed header, with a let declaration that creates the
> >>>>>>mapping between the created field and original uncompressed 
> >>>>
> >>>>field(s).
> >>>>
> >>>>>>However, control fields are different because they are not
> >>>>>>necessarily created directly out of uncompressed fields, at 
> >>>>
> >>>>least not
> >>>>
> >>>>>>on a per-packet basis, and they do require context. 
> >>
> >>This is why we
> >>
> >>>>>>agreed they should be explicitly declared as "control fields".
> >>>>>>
> >>>>>>I see three kind of fields, original fields, per-packet 
> >>>>>>created fields,
> >>>>>>and context-requiring created fields (control-fields).
> >>>>>>
> >>>>>
> >>>>>
> >>>>>Yes OK, I've been convinced that we can stick with just 
> >>>
> >>>these three.
> >>>
> >>>>>We already have syntax for "original" fields: 
> >>
> >>"uc_format". We also
> >>
> >>>>>have syntax for "context-requiring" fields: 
> >>>>
> >>>>"control_fields". We don't
> >>>>
> >>>>>have syntax for "created" fields. These are very 
> >>>
> >>>important and need
> >>>
> >>>>>defining explicitly in the FN draft, because they are 
> >>>
> >>>like no other
> >>>
> >>>>>kind of field: they can be compressed using "static", 
> >>>
> >>>"lsb" etc. but
> >>>
> >>>>>*without* using context of their own - they use the 
> >>
> >>context of the
> >>
> >>>>>field(s) which they are derived from. I suggest that we 
> >>
> >>call these
> >>
> >>>>>"derived_fields". This then is the only new syntactical 
> >>>>
> >>>>element which
> >>>>
> >>>>>we need.
> >>>>>
> >>>>>"default_methods" can then be used exclusively for 
> >>>
> >>>storing defaults,
> >>>
> >>>>>as described in the current FN draft.
> >>>>>
> >>>>>
> >>>>> 
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>>* It strikes me that there are quite a few different types 
> >>>>
> >>>>of field,
> >>>>
> >>>>>>>(e.g. "inferred" fields), which we are currently not 
> >>>
> >>>being explicit
> >>>
> >>>>>>>about, either in the FN or in the TCP draft. The notation 
> >>>>>>>(and hence the TCP draft) would be easier to read if we were
> >>>>>>>explicit about these things. At present we are 
> >>
> >>disguising them as
> >>
> >>>>>>>other things, which is confusing (to me at least). To 
> >>
> >>bring this
> >>
> >>>>>>>discussion full circle one such example is a non-default 
> >>>
> >>>statement
> >>>
> >>>>>>>appearing in a default list.
> >>>>>>
> >>>>>>I see what you mean, but this also worries me, as I 
> >>
> >>think we would
> >>
> >>>>>>open up the classic can of worms if we start doing these 
> >>>
> >>>things. We
> >>>
> >>>>>>are *very* close to finalizing the FN, and I do not want to run
> >>>>>>another round of redefining things that we have actually 
> >>>
> >>>agreed are
> >>>
> >>>>>>ok. Just sort out the control-fields and default-methods 
> >>>
> >>>stuff, and
> >>>
> >>>>>>then let's try to close this document once and for all.
> >>>>>
> >>>>>
> >>>>>Yes, I agree, my boss was asking me only this morning 
> >>>
> >>>about how much
> >>>
> >>>>>more effort this was going to take to get finished!
> >>>>>
> >>>>>Hopefully we can all agree on the above solution? This is a 
> >>>>
> >>>>good step
> >>>>
> >>>>>forward for both the TCP profile and also the FN I 
> >>
> >>think. Thanks!
> >>
> >>_______________________________________________
> >>Rohc mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/rohc
> >>
> > 
> > 
> > _______________________________________________
> > 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: Wed, 20 Apr 2005 13:10:49 +0200

>I don't really get you here. I am not talking about context updating, I am 
 >talking about properties related to their persistency in the context, what you 
 >previously referred to as "fields" with requirements on the context.

Ok, so let's try to explain this another way.
I guess you agree that in the _text_ in rohc-tcp, the fields "with context" 
needs to be explained explicitly and separate from other type of field (as 
section 6.3 does). Then, if the text calls them "control fields", "persistent 
control fields" or "monkeys from outer space" does not matter the least to me. I 
know we have had requests for those textual descriptions before we added it and 
I hope you agree that in the text, that separation is necessary.

So assuming that, my point is: Why shouln't the FN give me provisions to have 
this separation reflected in the FN code? The "user" will first read the draft's 
text and see that "ooooh, these fields have a different meaning, and where do I 
find them in the FN code?". If we have the same definition for these and other 
not-in-the-uncompressed-header-fields, we make it harder on the user and that's 
what I specifically do not want to do. Yes, the FN becomes slightly more complex 
if it contains one more "class" of field, but I'd rather have the complexity 
logded there than having harder-to-read FN code.
Hope that makes my motivations more clear to you even if you don't agree with them.

BR,
	Kristofer