Subject: RE: [rohc] FN control fields

From: "Finking, Robert" <[email-masked]>
Date: Thu, 21 Apr 2005 10:56:09 +0100

Excellent - thanks!

OK I'm happy to accept that, including your amendment, but since this was over an issue nobody else seems interested in I don't think there will be any objections.

Sorry for the misunderstanding, and thanks once again *everybody* for contributing.

Raffles

> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Thursday, April 21, 2005 10:08 AM
> To: Finking, Robert; Carsten Bormann
> Cc: [email-masked]; Lars-Erik Jonsson (LU/EAB)
> Subject: RE: [rohc] FN control fields
> 
> 
> 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: Kristofer Sandlund <[email-masked]>
Date: Thu, 21 Apr 2005 14:38:24 +0200

Ok everyone.

I've reluctantly updated tha packet formats with the changes discussed in this 
thread.

Therefore:
- sack_offset in sack_var_length_enc is now a control fields (to my great dismay)
- There are no let-statements in default_methods

So, now the packet formats are up to date with this. I'm going to write a mail 
with the remaining issues in a few minutes time.

/Kristofer