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

From: "Finking, Robert" <[email-masked]>
Date: Mon, 18 Apr 2005 10:09:40 +0100

> > let statements binding certain attributes
> 
> How do you know that?
> 
> What does
> 
> let(a:uncomp_value == b:uncomp_value)
> 
> bind?

I think Eilert asked this very question during the original discussion =) It binds both a:uncomp_value and b:uncomp_value (to each other).

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Finking, Robert" <[email-masked]>
Date: Mon, 18 Apr 2005 14:50:10 +0100

Hi Kris,

> thanks for trying to clear this up.

Thanks for helping =)

> > 
> > * "Control field" had previously meant *any* field which 
> does not appear in the uncompressed header (I think this is 
> where my misunderstanding came from)
> > 
> > * It is not just "control fields" (see definition in 
> previous bullet) which may have no need for context, but 
> there are also fields in the uncompressed header which 
> similarly have no need for context
> 
> Not sure exactly what you mean here. I'd say that "inferred" 
> and fields that are 
> always transmitted "in full" for all packet types would fall 
> into this category 
> (TCP checksum, PSH bit and possibly something else in 
> ROHC-TCP). Or do you mean 
> something else here?

Yes, if you look at the old versions of the draft (i.e. before I even
came on the scene), you'll see things like this: "control fields, i.e.
fields which appear in the compressed header to control the compression
in some way and do not appear in the uncompressed header at all".
However there's no reason not to cater for such inferred fields
separately from control fields - in fact those early versions of the
draft had a concept of "inferred" encoding methods in them.

Here are my current thoughts:

* It seems like a useful thing to be able to indicate the need for
context, but I don't understand why we are only interested in doing it
for fields which don't appear in the uncompressed header. Is there some
motivation that I'm missing? What problem are we solving here that
doesn't need solving for fields which reside in the uncompressed header?

* 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.

> 
> > 
> > * Knowing which fields need context is very useful for the 
> implementer, so given the above points, why not have some 
> syntax which indicates explicitly for all fields whether or 
> not they need context/don't need context?
> > 
> 
> That's a possible solution, but maybe a bit overkill 
> depending on what it would 
> look like. Do you have some suggestion of how to accomplish 
> this that you could 
> show before I say if I think it's a good idea or not?
> I think that if we define control_fields in text as I 
> suggested earlier, it 
> might be sufficient, but maybe it needs to be made more 
> formal like you said?

OK, I'll get my thinking cap on about some example syntax while you all
have a think about my bullets =)

Cheers

Raffles

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 19 Apr 2005 10:00:34 +0200

> for fields which don't appear in the uncompressed header. Is 
> there some motivation that I'm missing? What problem are we solving
> here that doesn't need solving for fields which reside in the 
> uncompressed header?

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).

> 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.

/L-E

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 19 Apr 2005 15:01:45 +0200

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)
> >>
> > 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.
> > 
> > 
> >  
> > 
> >> 
> >>
> > 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!
>

---

From: "Finking, Robert" <[email-masked]>
Date: Tue, 19 Apr 2005 14:09:00 +0100

Great, is that consensus? Carsten? Eilert?

Cheers

Raffles

> [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
> 
>