Subject: RE: [rohc] FN control fields

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

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: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 20 Apr 2005 16:01:19 +0200

> draft (albeit non-formal) we need to do something to handle them

In the FN context is mentionned not in terms of what/how things need be maintained but rather in terms of the operations with respect to the attributes of a field for the coding method to succeed, and we've (naively) mentionned context as a synonym of "attribute values". We could remove mentions of the context as this is a concept that lives in ROHC profiles.

> methods are used for that field).

Exactly.

/Ghyslain

---

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

>       decompressor, but are not part of the uncompressed 

Yes, this is a mistake - when I updated the draft after Washington I forgot to make the change there. I think however that I made the changes in other parts of the draft (at that time, I don't not what's the state now).

/Ghyslain

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 20 Apr 2005 16:09:16 +0200

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

It doesn't make sense, as it says control fields are transmitted
from compressor to decompressor, which is not always the case.
Neither is it much of a short summary of what a control field
actually is.

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

Well, as I have said in my previous mail, I do not care. If you
can get both GP and KS to agree on one single solution, then I
think we can move on. 

/L-E

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 20 Apr 2005 16:16:52 +0200

> Oops, yes good point! Please do suggest alternative text - 
> you have made lots of other useful suggestions during the 
> review process!

I leave that to Ghyslain!

/L-E

---

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

> Neither is it much of a short summary of what a control field

Oops, yes good point! Please do suggest alternative text - you have made lots of other useful suggestions during the review process!

> can get both GP and KS to agree on one single solution, then I

OK - thank you. I'm sorry that it is not ideal!

Regards

Raffles

---

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

LOL thanks for having a good sense of humour =)

Inline

Raffles

> From: Kristofer Sandlund [mailto:[email-masked]] 
> Sent: Wednesday, April 20, 2005 3:15 PM
> To: Finking, Robert
> Cc: [email-masked]
> Subject: Re: [rohc] FN control fields
> 
> 
> Hi all,
> 
> <flame>
> I have an even better solution, replace FN with box notation 
> and english!
> </flame>
> 
>  From what I understand of Ghyslains solution, all fields not 
> part of the 
> uc_format needs to be defined as control_fields, right?

No, that's not correct, only those with an uncompressed side (specifically those with a greater than zero uncomp_length). Which I think means almost all of those in your list dissapear - phew!

> If so, co_baseheader will have the following:
> control_fields =
>                           discriminator,
>                           ttl_hopl_outer_flag,
>                           seq_indicator,
>                           ack_indicator,
>                           ack_stride_indicator,
>                           window_indicator,
>                           ip_id_indicator,
>                           urg_ptr_present,
>                           tos_tc_present,
>                           ttl_hopl_present,
>                           list_present,
>                           header_crc,
>                           options_list;
> (not including those already defined global fields)
> 
> What I'm trying to point out here is that co_baseheader has 
> 21 different 
> co_formats, but only one place to declare the control_fields, 
> and of the fields 
> above, almost all are for co_common, and the other 20 formats 
> need to "see" the 
> other variables in their scope just because of this new way 
> of having control 
> fields.
> This is supposed to make things more clearer and simpler? (it 
> works, sure, but 
> this will clutter things to a point where I want to throw up).
> 
> This solution seems to me like we have to declare everything 
> one scope outside 
> of where it is needed. Ugly!
> 
> I hope someone with access to the CVS that isn't me makes 
> these ugly changes to 
> the tcp-pf *grumpy*
> 
> /Kristofer
> 
> 
> 
> Finking, Robert wrote:
> > Hi Ghyslain, Kris, All
> > 
> > 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:
> > 
> >  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).
> > 
> > - 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 move the non-default let statements in the FN-draft 
> AND tcp-pf out of the default section and into either a 
> > Robert Finking (01794 833189)
> > Roke Manor Research (http://www.roke.co.uk)
> > Romsey, Hampshire SO51 0ZN
> >

---

From: "Finking, Robert" <[email-masked]>
Date: Wed, 20 Apr 2005 16:14:28 +0100

Hi Carsten,

Many thanks for the input. The review comments on the control field section are useful as always. Can I ask you specifically about the current proposal (from the head of this thread - rationale contained therein):

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

Even if this is not ideal from your point of view, are you prepared to accept this? L-E and Kris (offline) have accepted it so far, albeit in a "not really what I wanted" sort of way! I'm hoping Ghyslain will be happy with it since it is very close to what he wants (I think maybe he may prefer it to apply to *all* fields which aren't in the compressed header though, not just those which have greater than zero uncomp_length).

Thanks again for your input everybody - this would be taking months otherwise!

Cheers

Raffles

> From: Carsten Bormann [mailto:[email-masked]] 
> Sent: Wednesday, April 20, 2005 4:00 PM
> To: Finking, Robert
> Cc: Lars-Erik Jonsson (LU/EAB); Carsten Bormann; [email-masked]
> 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
>

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 21 Apr 2005 10:58:27 +0200

> No, that's not correct, only those with an uncompressed side 
> (specifically those with a greater than zero uncomp_length). 
> Which I think means almost all of those in your list dissapear - phew!
 
So far, I have only discussed about properties of control fields, that I thought that we had agreed before that they have the same properties as uncompressed fields and can be used in the same manner. I also want to avoid talking about context (what the implementation needs to remember) in the FN.

Defining the fields in the notation in my understanding we were already doing as Robert explained, which also correspond to what I thought we had agreed. This is what I meant when I wrote that the uncomp value of control fields can be undefined (ok in FN) but that this attribute cannot then be used in an expression since it would also be undefined (not allowed in FN). So Robert's answer does correspond to what I previously understood was the agreement.

My proposal to define control fields was the following:

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

So, as you can't see actually I did not proposed anyting regarding how they can be defined, but this of course should be clarified somewhere in the FN.

/Ghyslain