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

From: "Finking, Robert" <[email-masked]>
Date: Mon, 18 Apr 2005 11:53:45 +0100

In a shocking reversal of his previous statement: "I think I'll hang back on this", FN editor "Raffles" said, "well in that case let's sort this whole thing out right now".

Seriously, I had somehow completely missed the original intent - probably absence from the meeting didn't help ;-) Since there are no 3095 implications, let's go ahead and clarify exactly what was originally intended and the motivations behind it. I'll state my personal concerns and we can thrash it out properly to reduce the chance of revisiting this again!

* The intent was to mark out fields which are not part of the uncompressed header and which  use context information (that's my interpretation of "to separate what is persistent or not...")

* The motivation for this is presumably that it is very useful to the implementer to know if a field needs context? (Otherwise they have to infer this from all the different encoding methods used for the field in all the different packet formats?)

* We also adopted control fields as a scoping mechanism to allow one part of a profile to "communicate" with another, without having to pass structure parameters across layers of the protocol stack (messy).

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

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

Regards

Raffles

> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Monday, April 18, 2005 10:54 AM
> To: Finking, Robert; Kristofer Sandlund
> Cc: [email-masked]
> Subject: RE: [rohc] FN: default_methods and control fields 
> clarification/new usage
> 
> 
> > Yes, it's easy to "say", but my concern is what it *means*. 
> > This is about 3095 compatibility. What does "control field" 
> > mean in 3095? Can't 3095 control fields have context? Are we 
> > about to break something? I'm no 3095 expert as you know, so 
> > help me out here =)
> 
> The only compatibility with 3095 we have to care about is 
> defined by profile specifications, which have to make sure
> there are no packet type collisions, i.e. that profile common
> packet formats are properly defined. There are also concerns
> related to feedback handling and other "framework issues", 
> but they are all part of the profile specification.
> 
> The FN is only about how to define formats, not about what to
> put in them, so I see no 3095 compatibility issues with the FN.
> 
> When it comes to the term "control field", it does not even
> exist in RFC 3095.
> 
> /L-E
> 

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Mon, 18 Apr 2005 14:09:38 +0200

Hi Robert,

thanks for trying to clear this up.

Comments inline.

> * The intent was to mark out fields which are not part of the uncompressed header and which  use context information (that's my interpretation of "to separate what is persistent or not...")

agreed

> * The motivation for this is presumably that it is very useful to the implementer to know if a field needs context? (Otherwise they have to infer this from all the different encoding methods used f…

Yep.

> * We also adopted control fields as a scoping mechanism to allow one part of a profile to "communicate" with another, without having to pass structure parameters across layers of the protocol stack…

Agreed.

> * 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 conte…

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?

> * 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 contex…

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?

BR,
	Kristofer Sandlund, Effnet AB