Subject: RE: [rohc] Replication packet type

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 15 Aug 2002 10:38:28 +0200

Richard,

> > Yes, this is the only bit pattern left. However, I would not say
> > we really need to leave any bit patterns for future framework 
> > extensions. I do not have any strong opinions about this, but we
> > would get a smaller identifier if we just go for 11111001
> 
> Reserving some bit patterns for future use doesn't have to 
> increase the overhead of the context replication mechanism. The
> context replication header will need to include a field that
> specifies the "source context" (i.e. the context that's being
> replicated). If we specify this as a delta offset from the
> "destination context" (i.e. the context that we're currently
> updating) then the field can't take the value zero since we can't
> replicate a context from itself. The "zero" bit pattern can then
> be reserved for future framework packets at no extra cost :-)

I am not sure defining the "source context" as a delta will be
the way to go, might be simpler to use an absolute CID value.
Anyway, your point is still valuable, even if we use up all
packet type identifiers, we will probably be able to find 
some patterns that can not appear for some types, and use
them if that becomes necessary. Let's look at this when we define
the replication packet, it might be easy to make that packet
type extendable. So then we can just go for 11111001, right?

> > and then we would basically close the framework, which could even be
> > seen as a good thing...=)
> 
> I think it's useful to keep at least one bit pattern in reserve, just
> in case the ROHC framework needs to be upgraded in the future. It's
> certainly more convenient than defining a new framework with a new PPP
> protocol field value, particularly if we make sure only to upgrade the
> framework in a backwards-compatible manner.

I do not think there will ever be a "need" to add things, it might appear
desirable at some point but never absolutely needed. We should remember
that although there might be some new header compression cases to address
later on, we have done the tricky parts and should not expect any
fundamentally new problems (that would require framework changes) to
appear in the future.

So, my conclusion is that although it is not necessarily important, we
should consider making 11111001 reusable by extending it when we define
the replication packet.

/L-E

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Aug 2002 14:57:08 +0200

> I do not think there will ever be a "need" to add things,

Hmm, famous last words.

Having missed out on the opportunity to provide extensibility in protocol 
designs before, my experience tells me that something new is just around the 
corner.  Something that we don't think about now, but will be painfully obvious 
when it has come into view.

Maybe we didn't pay enough attention when we "spent" the bit patterns available 
for their various uses in 3095.  Using up the last one does worry me.

Gruesse, Carsten