Subject: [rohc] ROHC-FN & ROHC-TCP: Control fields

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 21 Oct 2004 13:51:34 +0200

Hi!

Me and Ghyslain are trying to fix the final nits in the TCP packet formats, and 
with all the changes that the FN has undergone, it seems like the notion of 
control fields does not seem to be fully defined in the current WIP draft.

Basically, we have two types of control fields: those that need to be stored in 
context (e.g. MSN, IP-ID behavior, ecn_used, etc), and those that are just 
"compressed_value" (e.g. discriminators).
Those that update context are currently "defined" in default_methods or in the 
compressed format, which seems a bit weak, so we suggest that we add a 
"control_fields" section to encoding methods so that it is possible for the user 
to actually see which fields that need context. So, we might have:

some_enc === {
	 uncompressed_format = field1,
			       field2;

	 control_fields = msn;

	 format_1 = discriminator,
		    field1,
		    msn,
	 {
		discriminator ::= '100'
		field1 ::= irregular(16);
		msn ::= irregular(16);
	 }
}

With this syntax, it is clear which fields that are defined in this structure 
that sets context, which we don't think the old syntax does very well.

******************
Now, over to how to use control fields in the TCP draft.
Some control fields need to be known outside the scope of their definition, e.g. 
the ecn_used control field defined in the tcp header controls the presence of 
TOS bits in some compressed packets. So an example of the "problem" (using the 
syntax suggested above):

tcp ===
{
	uncompressed_format = ack_flag,
				......

	control_fields = ecn_used,
		         msn;
			
         format_tcp_dynamic =  ecn_used,              %[ 1 ]
                               ack_flag,              %[ 1 ]
                               urg_flag,              %[ 1 ]
                               psh_flag,              %[ 1 ]
				......
}

co_baseheader ===
{
	uncompressed_format = <lists all fields from innermost IP + TCP>
	
	control_fields = ecn_used,
		         msn,
			 ipid_behavior; % IPID behavior in innermost IP
	format_xxx.....
}

ipv4 ===
{
	......

         format_ipv4_outer_irregular = ip_id,
                                       tos_tc,
                                       ip_ecn_flags,
         {
                 ip_id_behavior ::= static;
                 ip_id          ::= ip_id_enc_irreg (ip_id_behavior);
                 tos_tc         ::= irreg_tos_tc (ecn_used); <----------
                 ip_ecn_flags   ::= ip_irreg_ecn (ecn_used); <----------
         };

}

The "ecn_used" context control field is something that is used both in TCP and 
in the base header (quite natural since the base header is an IP + a TCP 
header), and it is referenced in the IPv4 structure. Clearly, the ecn_used in 
the ipv4 structure needs some way to make a reference to something that is 
defined outside of its own scope.

Questions:
  1) How is the user supposed to know that the ecn_used in the base header 
should be the same field that was established by the dynamic chain in the TCP 
header?
  2) How should the IPv4 structure refer to this field since it is outside its 
own scope?

An answer to the second question might be to define a "global" constant 
(constants are defined in 4.2 of the latest WIP FN) that gets a new value when 
the ecn_used context value is changed, i.e. something along the lines of:

ECN_USED = 0;

co_baseheader ===
{
	uncompressed_format = <lists all fields from innermost IP + TCP>
	
	control_fields = ecn_used,
		         msn,
			 ipid_behavior; % IPID behavior in innermost IP

	format_xxx = ecn_used,
		     blah,
	{
		ecn_used ::= some_encoding();
		let (ECN_USED == ecn_used:uncomp_value);
		blah ::= some_other_encoding;
	}
}

ipv4 ===
{
	......

         format_ipv4_outer_irregular = ip_id,
                                       tos_tc,
                                       ip_ecn_flags,
         {
                 ip_id_behavior ::= static;
                 ip_id          ::= ip_id_enc_irreg (ip_id_behavior);
                 tos_tc         ::= irreg_tos_tc (ECN_USED);
                 ip_ecn_flags   ::= ip_irreg_ecn (ECN_USED);
         };

}

I have no idea if this is actually legal with the FN, but it seems good enough, 
so I'm are going to put this into the packet formats for now, but it can always 
be changed to something else if there is disagreement.

BR,
	Kristofer Sandlund, Effnet AB
	Ghyslain Pelletier, Ericsson

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2004 16:17:08 +0200

On Oct 21 2004, at 13:51 Uhr, Kristofer Sandlund wrote:

> Hi!
>
> Me and Ghyslain are trying to fix the final nits in the TCP packet 
> formats, and with all the changes that the FN has undergone, it seems 
> like the notion of control fields does not seem to be fully defined in 
> the current WIP draft.
>
> Basically, we have two types of control fields: those that need to be 
> stored in context (e.g. MSN, IP-ID behavior, ecn_used, etc), and those 
> that are just "compressed_value" (e.g. discriminators).

The problem is that FN currently does not say anything about the 
context.

> Those that update context are currently "defined" in default_methods 
> or in the compressed format, which seems a bit weak, so we suggest 
> that we add a "control_fields" section to encoding methods so that it 
> is possible for the user to actually see which fields that need 
> context.

That is an interesting proposal.
I would feel better if we could flesh out more of the context side of 
the FN (as opposed to the uncompressed and the compressed side); once 
we start to really understand this, we might want to have more (or 
different) ways of saying this.

> With this syntax, it is clear which fields that are defined in this 
> structure that sets context, which we don't think the old syntax does 
> very well.

How about an annotation?

> Some control fields need to be known outside the scope of their 
> definition, e.g. the ecn_used control field defined in the tcp header 
> controls the presence of TOS bits in some compressed packets.

Now it gets interesting -- but you are not talking about the context 
(in the sense of inter-packet memory), but you want to link different 
parts of the spec using the same concept.

Right now, we only have encoding method parameters for this purpose, 
and (having done some work on 3095-FN) I know that this can get rather 
long in the tooth.
It is doable, though.

In your example, are you using ecn_used as a field name or as a number?
I'm seeing both, which is confusing.

>  1) How is the user supposed to know that the ecn_used in the base 
> header should be the same field that was established by the dynamic 
> chain in the TCP header?

You would have to use a parameter.

>  2) How should the IPv4 structure refer to this field since it is 
> outside its own scope?

Ditto.

> An answer to the second question might be to define a "global" constant

Well, I'd try not to mingle this with constants (which are, kind of, 
constant).

> 		let (ECN_USED == ecn_used:uncomp_value);

This looks like a "global parameter", i.e. an implicit parameter of 
*every* encoding method that is handed down to *every other* encoding 
method.

Again, this *can* be done using existing notation; however, if you have 
too many of these parameters, the parameter lists do get rather long 
(which you can see in 3095-FN).  Maybe Eilert can produce an example 
(I'm off to other things right now, unfortunately).

Gruesse, Carsten

---

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 21 Oct 2004 16:34:06 +0200

Comments inline.

Carsten Bormann wrote:
> The problem is that FN currently does not say anything about the context.
> 
>> is possible for the user to actually see which fields that need context.
> 
> 
> the FN (as opposed to the uncompressed and the compressed side); once we 
> start to really understand this, we might want to have more (or 

Yes that is probably needed, but for the next revision we'll go with this 
temporary solution, and we can hopefully flesh out something in Washington.

>> structure that sets context, which we don't think the old syntax does 

I thought we'd agreed during our long discussion a few weeks ago that 
"annotations do not have any formal meaning", so I that would rule out 
annotations for this.

> Now it gets interesting -- but you are not talking about the context (in 
> the sense of inter-packet memory), but you want to link different parts 
> of the spec using the same concept.
> 
> Right now, we only have encoding method parameters for this purpose, and 
> (having done some work on 3095-FN) I know that this can get rather long 
> in the tooth.
> It is doable, though.
> 

Yep, I forgot to set ":uncomp_value" in some places, so it should have looked 
like this:
                 tos_tc         ::= irreg_tos_tc (ecn_used:uncomp_value);
                 ip_ecn_flags   ::= ip_irreg_ecn (ecn_used:uncomp_value);

> You would have to use a parameter.

But..... since we're doing the "chain" definition in English due to all the 
issues with this, the construction is done by the "user" and therefore 
parameters seem a bit awkward. But OTOH, I might just do that in English as well 
to say that the parameter should be taken from the TCP context.

> *every* encoding method that is handed down to *every other* encoding 

Yes, I agree that this is not very good, but I just want something out the door 
and at least I managed to get a reaction and suggestions this time :)

> (I'm off to other things right now, unfortunately).

Any help appreciated!

BR,

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2004 16:50:27 +0200

> "annotations do not have any formal meaning", so I that would rule out 

Actually, the whole concept of context has no formal meaning at the 
current state, so this would not be a contradiction.

Gruesse, Carsten