Subject: RE: [rohc] FN control fields

From: "Finking, Robert" <[email-masked]>
Date: Wed, 20 Apr 2005 15:00:56 +0100

That is the definition in the terminology section, terse I'll admit, but it makes sense to me - feel free to suggest alternative words though. The Control Fields section says:

<quote>
4.9.5 Control Fields

Control fields are defined using the "control_fields" list. 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). Such fields may be used to help compress fields from the uncompressed header more efficiently. A control field could be used to improve efficiency by representing some commonality between a number of the uncompressed fields, or by representing some information about the flow that is not explicitly contained in the protocol headers.

For example in IP, the behaviour of the IP-ID field in a flow varies depending on how the endpoints handle IP-IDs. Sometimes the behaviour is effectively random, sometimes the IP-ID follows a predictable sequence, and at other times it stays fixed at zero. The type of IP-ID behaviour is information that is never communicated explicitly in the uncompressed header. However, a ROHC profile can still be designed to identify the behavior and adjust the compression strategy according to the identified behaviour, thereby improving the compression performance. To do so, the profile can introduce an explicit field to communicate the IP-ID behaviour in compressed headers, and in ROHC-FN terms this is done by introducing a control field

<snip examples>

Control fields may also be used with global scope. In this case their declaration must be outside of any structure. They are then visible within any structure thus allowing information to be shared between structures directly.
</quote>

Which hopefully makes sense? In light of this, what do you think of the suggestion - would you accept it?

Raffles

> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Wednesday, April 20, 2005 2:46 PM
> To: Finking, Robert; [email-masked]
> Subject: RE: [rohc] FN control fields
> 
> 
> And the definition of control-field would then be as given by 
> Ghyslain?
> CSoP in the FN draft is the following, which does not make 
> sense, I think:
> 
> o  Control field
> 
>       Control fields are transmitted from a ROHC compressor to a ROHC
>       decompressor, but are not part of the uncompressed 
> header itself.
> 
> /L-E
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Finking, Robert
> > Sent: den 20 april 2005 15:31
> > To: [email-masked]
> > Subject: [rohc] FN control fields
> > 
> > 
> > Hi Ghyslain, Kris, All
> > 
> > Wow! You go to a morning meeting and while you're away the 
> > list explodes. Many thanks to you all for your contributions. 
> > OK taking into account the whole discussion, here are the 
> > main points as I see them:
> > 
> >  - We don't have consensus
> >  - The main obstacle is Kris and Ghyslain's disagreement
> >  - They both live in Luleå
> > 
> > Therefore I suggest an arm wrestling competition at sunset in 
> > the car park outside Ghyslain's apartment =) 
> > 
> > Seriously, this is a fairly involved issue and I'm very glad 
> > Ghyslain has joined in - thanks! The main points:
> > 
> >  1 Some want to be able to indicate need for context, others don't
> >  2 The current state of play (CSoP) in the FN draft is the latter
> >  3 The CSoP in the TCP-pf is the former
> >  4 The FN draft will have to change if it adopts the former
> >  5 The TCP-pf will NOT have to change if it adopts the 
> > latter, the FN in the TCP-pf will be the same either way but 
> > have a subtly different meaning
> >  6 It would be very good if we can fix the "non-default 
> > default let statements" bug as part of this
> >  7 we have endeavoured to remove formal references to context 
> > from the FN as part of the simplification we did last summer
> >  8 "derived" fields are currently not discussed at all in the 
> > FN draft, but since *some* mention is made of context in the 
> > draft (albeit non-formal) we need to do something to handle them
> >  9 The information about whether context is needed is already 
> > there in the profile, implicitly (in terms of what encoding 
> > methods are used for that field).
> > 
> > Here is my suggestion, which will hopefully fit all parties 
> > to an OKish degree:
> > 
> > - we stick with the current syntax, which keeps things simple 
> > and minimises the changes necessary
> > - in the TCP-pf we can use comments to indicate that context 
> > is needed for certain fields
> > - we clarify in the FN draft the possibility of the existence 
> > of derived fields and their use; again these can optionally 
> > be indicated by comments
> > - we clarify in the FN draft that "control_fields" sections 
> > are just like any other section inside a structure in that 
> > they may have a field encodings list.
> > - we move the non-default let statements in the FN-draft AND 
> > tcp-pf out of the default section and into either a 
> > "control_fields" field encodings list, or a "uc_format" field 
> > encodings list if that is more convenient.
> > 
> > Did I give a fair summary, and how does my suggestion sit 
> > with everyone? I'm guessing nobody will be over the moon 
> > about it, but hopefully all can just about swallow it?
> > 
> > Here's hoping!
> > 
> > Raffles
> 

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Apr 2005 17:00:17 +0200

The control_field section we invented at IETF61 were a way to say, for 
a field: the uncompressed side of the field is somehow supplied by the 
profile/state machine.
(Without the control_field section, this would have to be expressed by 
parameters and let statements, which for nested encoding methods can 
become awkward quickly, so this is a welcome shorthand).

Now let's see:

> <quote>
> 4.9.5 Control Fields
>
> Control fields are defined using the "control_fields" list. The 
> control fields list specifies all fields that do not appear in the 
> uncompressed header

Well, typically, they don't. (This is not a requirement.)

> but which have an uncompressed value

all fields do.

> (specifically those with a non-zero uncomp_length).

That's what you mean, OK.

> Such fields may be used to help compress fields from the uncompressed 
> header more efficiently.

(I hope that's true of everything we can do in FN.)

> A control field could be used to improve efficiency by representing 
> some commonality between a number of the uncompressed fields, or by 
> representing some information about the flow that is not explicitly 
> contained in the protocol headers.

This seems to be alluding to the fact that the information supplied by 
the profile/state machine is often something we have called context in 
earlier documents.
I think we long agreed that we didn't know how to represent context in 
FN, so control_fields was a good way to punt this issue.

> For example in IP, the behaviour of the IP-ID field in a flow varies 
> depending on how the endpoints handle IP-IDs. Sometimes the behaviour 
> is effectively random, sometimes the IP-ID follows a predictable 
> sequence, and at other times it stays fixed at zero. The type of IP-ID 
> behaviour is information that is never communicated explicitly in the 
> uncompressed header. However, a ROHC profile can still be designed to 
> identify the behavior and adjust the compression strategy according to 
> the identified behaviour, thereby improving the compression 
> performance. To do so, the profile can introduce an explicit field to 
> communicate the IP-ID behaviour in compressed headers, and in ROHC-FN 
> terms this is done by introducing a control field

Wait, wait, wait.
First of all, this is another example of mixing definition with example.
(We have to make sure all examples are clearly identified as such!)
Second: This text seems to suggest we send a bit or two in every 
compressed packet that identifies the IP-ID encoding variant being 
used.
Of course the point here is that the profile/state machine can remember 
and supply this information -- as a control_fields field!

> Control fields may also be used with global scope. In this case their 
> declaration must be outside of any structure. They are then visible 
> within any structure thus allowing information to be shared between 
> structures directly.

Essentially, I think this is saying that a globally declared 
control_fields field is visible in every structure.
(Which is fine, as field that isn't used does not harm.)
It also means that the profile/state machine has to supply these values 
for every "call" to a structure (i.e., the field becomes an implicit 
part of the interface between the part specified by the FN 
specification and the profile/state machine).  This can sometimes hurt 
a bit, but I think is mitigated by the fact that if a control_fields 
field is not used, it does not matter what is being supplied here.

Gruesse, Carsten