Subject: RE: [rohc] FN control fields

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

Carsten, Robert,

Robert, thanks for summarizing and bringing order to this discussion.
And thanks Carsten for clarifying what we had agreed in Washington, I think corresponds with what I tried (but obviously failed to) explain clearly since it seem to agree with treating control_fields just like uncompressed fields in terms of their properties, as well as avoiding talking anything related to context and persistency of fields thereof.

Comments inline.

/Ghyslain

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Finking, Robert
> Sent: den 20 april 2005 17:14
> To: 'Carsten Bormann'
> Cc: [email-masked]; Lars-Erik Jonsson (LU/EAB)
> Subject: RE: [rohc] FN control fields
> 
> 
> 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

Yes please.

> - in the TCP-pf we can use comments to indicate that context 
> is needed for certain fields

Ok. This is in the profile document, thus the correct scope in my opinion.

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

No, I disagree. But we could mention that it is up to the profile specification to provide guidelines on lifetime/persistency/updating/whatever how different values of attributes of different types of fields need to be maintained. But please don't define something new with new terms e.g. "derived fields" without have any formal meaning or use in the FN.

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

Yes please.

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

This seems to address the issue that started it all properly.
 
> 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).

No no, this is a misunderstanding that was created from Kristoffer's interpretation of what I wrote! See my previous mail(s).
 
> Thanks again for your input everybody - this would be taking 
> months otherwise!

Thanks Robert. Case closed?
 
> Cheers
> 
> Raffles
> 
> 
> > -----Original Message-----
> > 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]
> > Subject: Re: [rohc] FN control fields
> > 
> > 
> > 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
> > 
> 
> _______________________________________________
> 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: Carsten Bormann <[email-masked]>
Date: Thu, 21 Apr 2005 16:28:05 +0200

It's nice that we seem to have consensus, but I still don't know what

> uncompressed fields

are.  All fields have a compressed and an uncompressed side.  Do you 
mean a field whose uncompressed side actually is being used in an 
uncompressed format field list?

Gruesse, Carsten