Subject: RE: [rohc] ESP NULL again (padding)

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 18 Sep 2003 10:34:39 +0200

Kristofer,

In what way is this important for interoperability? It seems
like an implementation issue. The only thing I can see as an
interoperability issue is whether the Pad Length can be trusted, 
which is something the current text does not mention.

One idea: Is it so that we want to make sure the "padding content"
is the same after compression, i.e. if it is not always the same
in all packets?
If so, then I think the 3095 text is correct.

BR
/L-E

> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: den 16 september 2003 13:44
> To: [email-masked]
> Subject: [rohc] ESP NULL again (padding)
> 
> 
> Hi all,
> 
> I have one more issue with the ESP NULL header in the list 
> compression that I 
> feel is something that could be added in the upcoming 
> implementer's guide update.
> 
>  From 5.8.4.3 (ESP NULL header):
> 
>  >      Padding: The padding octets are assumed to be as 
> defined in [ESP],
>  >          i.e., to take the values 1, 2, ..., k, where k = 
> Pad Length.
>  >          If the padding in the static context has this 
> pattern, padding
>  >          in compressed headers is assumed to have this 
> pattern as well
>  >          and is removed.  If padding in the static context does not
>  >          have this pattern, the padding is not removed.
> 
> Which seems to suggest that the ESP padding should be added 
> to the static 
> context, and this is the only part of the spec that seems to 
> mention this.
> It seems a bit strange, since an ESP NULL list item is sent 
> as part of the 
> dynamic chain (do I update the static part of the context 
> because of a change in 
> a header that is sent as part of the dynamic chain?)... Does 
> this suggest that 
> the 'ESP NULL trailer' should be considered part of the 
> static chain? This seems 
> really wierd to me.
> Also, why do I need to store the padding itself in the 
> context? It should be 
> sufficient with a flag saying if the padding is compressible 
> or not, since the 
> pad length is always sent and can take on different values 
> for each packet.
> 
> Shouldn't it be expressed more like:
> 
> "When an uncompressed ESP NULL item is received, a flag MUST 
> be set in the 
> dynamic context of the decompressor indicating whether the 
> ESP padding will be 
> removed or not in compressed ESP NULL items. If this flag is 
> set, padding is 
> assumed to take the values 1, 2, ..., k, where k = Pad 
> Length. When the flag is 
> not set, the padding is always sent as-is."
> 
> Does this make more sense?
> 
> Rgds,
>      Kristofer Sandlund, Effnet AB
> 
> 
> _______________________________________________
> 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, 18 Sep 2003 11:17:10 +0200

Lars-Erik,

you're right that it is an implementation issue whether you use a flag or the 
exact padding, so I went a bit overboard there. Ignore that part.

My concern was mostly the fact that the text implicitly tells me to update the 
"static context" with something from the dynamic chain. That's a bit ugly, but I 
guess that does not affect interoperability, so you probably don't need to 
update the impl.guide for that.

Rgds,
	Kristofer