[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] FN: default_methods and control fields clarification/new usage
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: rohc-bounces at ietf.org [mailto:rohc-bounces at ietf.org]On Behalf Of
> Finking, Robert
> Sent: den 19 april 2005 15:09
> To: 'Carsten Bormann'
> Cc: rohc at ietf.org
> 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:lars-erik.jonsson at ericsson.com]
> > Sent: Tuesday, April 19, 2005 2:02 PM
> > To: Kristofer Sandlund; Finking, Robert
> > Cc: rohc at ietf.org
> > 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:kristofer.sandlund at effnet.com]
> > > Sent: den 19 april 2005 13:41
> > > To: Finking, Robert
> > > Cc: Lars-Erik Jonsson (LU/EAB); rohc at ietf.org
> > > 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
> 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