Subject: RE: [mobile-ip] Piggybacking - DT recommendation

From: Phil Roberts <[email-masked]>
Date: Tue, 19 Feb 2002 17:13:18 -0500

I *think* we're getting into enough info about specific L2s to confuse
the issues, but not enough info to clarify them.  There are layers
of framing, for example....

So, could we avoid this bit of rathole, or is it essential for the
discussion?

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Tuesday, February 19, 2002 2:04 AM
> To: James Kempf; [email-masked]
> Subject: Re: [mobile-ip] Piggybacking - DT recommendation
> 
> 
> > I think what you mean is two or more IP packets per 
> scheduled packet 
> > transmission slot. Radio L2 frame sizes vary, of course, 
> but on most 
> > cellular systems they are on the order of 40 bytes. This 
> would be just 
> > enough to carry one uncompressed IPv6 header with no header options.
> 
> Particularly with v6, there *has* to be header compression. I 
> wonder how many voice packets you could fit on 40 bytes with 
> compression... As far as changing 3GPP or 3GPP2 goes I too 
> think it's hard but maybe not *so* hard. There's for instance 
> examples on how fast those folks have adopted header 
> compression when they have seen the benefits. Come to think 
> of it, maybe I should I ask my compression colleagues if they 
> have thought of putting multiple packets on a single frame...
> 
> Jari
> 
> 
>

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 20 Feb 2002 08:31:52 +0200

> So, could we avoid this bit of rathole, or is it essential for the

I think we could probably avoid this discussion. We know the
theoretical possibilities anyway, such as that link layers could
employ header compression, could pack several packets onto
a single frame, might have QoS channels, etc. Or then again might
not have any of these. Assuming v6 lives longer than v4, the
relevance of current specific link layers might not be so great.

Jari

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 20 Feb 2002 08:15:30 -0500

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Wednesday, February 20, 2002 1:32 AM
> To: Phil Roberts; [email-masked]; James Kempf
> > the issues, but not enough info to clarify them.  There are 
> layers of 
> > framing, for example....
> > 
> theoretical possibilities anyway, such as that link layers 
> could employ header compression, could pack several packets 
> onto a single frame, might have QoS channels, etc. Or then 
> again might not have any of these. Assuming v6 lives longer 
> than v4, the relevance of current specific link layers might 
> not be so great.
>
There is no reason why multi-packet blocking has to be link-layer
specific, any more than IPHC is link-layer specific. Some compression
schemes have link-layer dependencies (e.g. cRTP), but that's because
they are trying to compress the link-layer headers as well. I think that
punting multi-packet blocking as a "theoretical" alternative to
piggybacking because "current link layers don't do it" would be a
mistake.

Note that there was an interesting I.D. by Mark Handley a couple of
years ago that did this for RTP. He wrote it as an alternative to some
bizzare RTP multiplexing schemes that people were proposing at the time.
We could look at it for guidance if there's any interest in pursuing
this direction.

Now, if people reach consensus that piggybacking isn't problematical for
BUs with IPv6, then looking at alternatives like blocking is
de-focusing. OTOH I do not see such a consensus emerging, even after
nearly a year of arguing.

Dave.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 20 Feb 2002 11:44:39 -0800

> nearly a year of arguing.

What do you think about my suggestion that managing resources on tight
data channels is, in essence, a QoS problem?  I thought this was pretty
clear; the very statement that a particular channel needs to be reserved
purely for one kind of data stream is almost tautologically a QoS problem.
I note in this connection, that even the most fervent proponents of
eliminating
piggybacking have no solution to offer if some other node sends a packet
to the bandwidth-constrained channel which is currently consumed with
the single-sized packet stream.  An appropriate QoS solution would,
on the other hand, solve both problems neatly.

I am optimistic that we will reach consensus soon.  I really think there is
an answer that will satisfy everyone's needs.

Regards,
Charlie P.

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 21 Feb 2002 23:39:31 -0500

> [mailto:[email-masked]] On Behalf Of 
> Charlie Perkins
> Sent: Wednesday, February 20, 2002 2:45 PM
> To: David Oran
> Cc: [email-masked]
> > Now, if people reach consensus that piggybacking isn't 
> problematical 
> > for BUs with IPv6, then looking at alternatives like blocking is 
> What do you think about my suggestion that managing resources 
> on tight data channels is, in essence, a QoS problem?  
Sure, just as jitter is a QoS problem. Are there in fact any arguments
in favor of piggybacking that AREN'T QoS arguments? I have to admit that
I am following this whole thing with about 2% of my brain capacity,
because my day job is completely unrelated, and the signal to noise
ratio on the mailing list is abysmal.

So, if you want to take the trouble to educate me via a private
back-channel, I'm game (although as a non-combatant in this debate you
might wish to put your efforts elsewhere).

What I'm struggling to understand is whether there are any CAUSAL or
TEMPORAL dependencies between the BU and the data it is piggybacked with
that can actually be exploited. If so, then either nobody has clearly
articulated them on the mailing list, or I am losing it. If not, then
you'll have to explain to me how piggybacking is more than a QoS
technique to cut down on bandwidth and amortize a channel scheduling
slot across two packets.

> I 
> thought this was pretty clear; the very statement that a 
> particular channel needs to be reserved purely for one kind 
> of data stream is almost tautologically a QoS problem. 
I think there are in fact other motivations besides QoS for separate
channels (e.g. secure demultiplexing, redundancy, quasi-related control
channels like power reporting on CDMA) but I don't think any of them
apply to the current debate, so let's leave this out of the discussion.

> I note 
> in this connection, that even the most fervent proponents of 
> eliminating piggybacking have no solution to offer if some 
> other node sends a packet to the bandwidth-constrained 
> channel which is currently consumed with the single-sized 
> packet stream.  An appropriate QoS solution would, on the 
> other hand, solve both problems neatly.
> 
The situation you allude to is one where the bottleneck link is *not*
the link emanating from the original transmitter, right? Well, in fact a
smart flow-based channel scheduler would not run into difficulty with
cross-traffic as long as bursts from original sources stay together
(which they tend to if not explicitly broken up). So, explain why
piggybacking wins here (again, I'm operating under the assumption of no
causal or temporal dependency). I would think splitting the BU from the
data packet would win (assuming moderate header compression efficiency)
because you could mark the jitter-sensitive data with EF, while letting
the BU go best effort. I *must* be missing something here since my cRTP
an LFI measurements on bandwidth-constrained links all seem to confirm
this. 

My suggestion of using packet blocking at the L3/L2 interface is simply
to optimize channel scheduling. This can win even on relatively fast
links, like DOCSIS uplinks.

> I am optimistic that we will reach consensus soon.  I really 
> think there is an answer that will satisfy everyone's needs.
>
Good luck! I wish I understood the benefits of piggybacking better,
since they're just not obvious to me.

Dave.

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 21 Feb 2002 21:55:14 -0800

Hello Dave,

Continuing...  I hope you'll be able to carry this discussion a bit further.

"David R. Oran" wrote:

> in favor of piggybacking that AREN'T QoS arguments?

My basic premise is that "piggybacking" is actually just another
word for basic IPv6 functionality.  IPv6 allows IP options to be
encoded in extension headers.  Binding Update is an IP option
encoded in an extension header.  IPv6 allows such things to have
payloads.  It turns out that this is a performance enhancement
in general for all links that implement IPv6 MTU.

> might wish to put your efforts elsewhere).

I wish it weren't combat in anyone's mind.

> technique to cut down on bandwidth and amortize a channel scheduling

The payload and the IP option signaling are logically able to be
separated, or otherwise people would not be arguing about it.
Thus, I don't think you can find the answer there.  I believe that
logical processing flow indicates a reasonable win for piggybacking.

But I don't think it is fair to equate all performance improvements as
"QoS issues".  I expect you already know this.  I would rather think
of QoS as a way to "reserve resources".  The proponents of removing
the basic IPv6 functionality of including payload with IP options/
extensions want to reserve resources without explicitly saying
so, by the brute force mechanism of just saying no.  This is on the
assumption that they are already claiming IPv6 conformance of the
underlying link.  If the latter is not so, then I think the situation is
even worse.

> > I thought this was pretty clear; the very statement that a

O.K.,  but in the abstract my statement still holds without reference
to any such layer-2 features.

> the link emanating from the original transmitter, right?

I was thinking about the bottleneck link at the receiver.

> Well, in fact a
> (which they tend to if not explicitly broken up).

This smart flow-based scheduler is then likely to perform some sort
of implicit QoS by snooping the packets to make sure they deserve
this preferential treatment.  Otherwise, you just cannot be sure that
such bursts will stay together, unless you somehow manage to avoid
sending other kinds of data.  The latter sounds like putting the whole IPv6
platform back on restrictions that make it resemble circuit-switched
voice.  Why do we want to go that direction?

> So, explain why

Well, the way you say it here, of course I have to agree, because marking
jitter-sensitive data with EF amounts to doing some sort of QoS
signaling, and I have been trying to suggest that such signaling is exactly
what is needed to make things work that way.  Furthermore, I suggest that
such signaling should, on appropriate links, cause the packet scheduler
to assign the separate microflows to separate channels.  Finally, it seems
likely  that the initial signaling (end-to-end) could cause the
application to exert the appropriate controls so that Binding Updates
are separated out if that is needed by the bandwidth manager on the
appropriate link.  This isn't absolutely necessary, though.  I can imagine
that the voice/control signaling packets could be fragmented across
both bearer channels for even better performance.  I don't see that
it is very likely people would design systems that way, but they could.

> links, like DOCSIS uplinks.

I'm not at all against such things.  I only say that we don't need to solve
that problem in order to move forward.  That would be a lot of work.
We just have to agree not to break basic IPv6 functionality.

> since they're just not obvious to me.

The benefits are as previously noted:
- Reduced jitter
- Fewer media accesses
- Natural processing (using already existing IPv6 code)
- Some reduction in bandwidth utilization
- Probably better compression, depending on how
  compression/decompression engines handle separate
  microflows.

Regards,
Charlie P.

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 22 Feb 2002 10:04:02 -0500

> From: Charlie Perkins [mailto:[email-masked]] 
> Sent: Friday, February 22, 2002 12:55 AM
> To: David Oran
OK, but you're not going to like what I have to say. Now that you've
clarified your technical arguments in favor of piggybacking, I find them
less persuasive than before rather than more.

I didn't want to get sucked in here. AD's and WG chairs - if I'm just
stirring the pot here and not helping, just send me a private note and
I'll be MORE than happy to shut up.

Dave.

My comments are inline:
 
> "David R. Oran" wrote:
> 
> > > What do you think about my suggestion that managing resources on 
> > > tight data channels is, in essence, a QoS problem?
> My basic premise is that "piggybacking" is actually just 
> another word for basic IPv6 functionality.  IPv6 allows IP 
> options to be encoded in extension headers.  Binding Update 
> is an IP option encoded in an extension header.  IPv6 allows 
> such things to have payloads.  It turns out that this is a 
> performance enhancement in general for all links that 
> implement IPv6 MTU.
> 
I believe that the BU is actually a special case, compared with other
options. All the other options I know of (correct me if I'm wrong) are
there to influence the processing of *the packet in which they are
placed*, either by intermediate routers or the destination host (in
other words, they would not be effective if sent in a different packet).
The BU piggybacking does not change the handling of the packet
containing the BU, but instead is a separate control signal to ask for
the installation of a binding cache entry for return packets to the
sending host. Said a different way, since unlike other options you CAN
send the BU in a separate packet, why piggyback it? Your contention is a
substantial performance win, worth making things more complicated in
other dimensions (e.g. IPSEC processing).

On the issue of substantial performance improvement, if you assume
header compression is in place on low-bandwidth links, it is far from
clear to me that "this is a performance enhancement in general for all
links that implement IPv6 MTU". Perhaps you could elaborate on how it
wins compared to plain header compression (apart from the channel
scheduling argument, which I understand and later argue that blocking at
the L3/L2 interface is equally or more effective at).

> > TEMPORAL dependencies between the BU and the data it is piggybacked 
> > with that can actually be exploited. If so, then either nobody has 
> > clearly articulated them on the mailing list, or I am losing it. If 
> > not, then you'll have to explain to me how piggybacking is 
> more than a 
> > QoS technique to cut down on bandwidth and amortize a channel 
> > scheduling slot across two packets.
> 
> The payload and the IP option signaling are logically able to 
> be separated, or otherwise people would not be arguing about 
> it. Thus, I don't think you can find the answer there.  I 
> believe that logical processing flow indicates a reasonable 
> win for piggybacking.
> 
That's where I'm lost. What about the "logical processing flow" produces
the win for piggybacking?

> But I don't think it is fair to equate all performance 
> improvements as "QoS issues".  I expect you already know 
> this.  
Well, on intermediate nodes I do think all the improvements are "QoS
issues". On the source and destination hosts, I'll grant your point, but
I'm still struggling to see just what those performance improvements
are. Sorry to be so dense!

> I would rather think of QoS as a way to "reserve 
> resources".  
Don't tell the diffserv guys that :-)

> The proponents of removing the basic IPv6 
> functionality of including payload with IP options/ 
> extensions want to reserve resources without explicitly 
> saying so, by the brute force mechanism of just saying no.  
I'm not following this part. Are you equating packet scheduling and
channel scheduling with "reserving resources"? I don't. I think of
reserving resources as putting them aside ahead of time and denying use
to others on the speculation that traffic will arrive to use those
resources. Clearly some layer 2's need to do this to minimize latency
(e.g. cellular, docsis), but I don't see how this affects the question
of piggybacking versus alternatives.

> This is on the assumption that they are already claiming IPv6 
> conformance of the underlying link.  If the latter is not so, 
> then I think the situation is even worse.
>
You've lost me. Sorry. I don't see how any of this has to do with
whether the link is capable of handling arbitrary IPv6 traffic, only
with what the QoS tradeoffs are for various traffic patterns arriving
for that link.

> > > particular channel needs to be reserved purely for one 
> kind of data 
> > > stream is almost tautologically a QoS problem.
> > channels (e.g. secure demultiplexing, redundancy, quasi-related 
> > control channels like power reporting on CDMA) but I don't 
> think any 
> > of them apply to the current debate, so let's leave this out of the 
> > discussion.
> 
> O.K.,  but in the abstract my statement still holds without 
> reference to any such layer-2 features.
>
Yes, and I agree.
 
> > > eliminating piggybacking have no solution to offer if some other 
> > > node sends a packet to the bandwidth-constrained channel which is 
> > > currently consumed with the single-sized packet stream.  An 
> > > appropriate QoS solution would, on the other hand, solve both 
> > > problems neatly.
> > >
OK, but is there anything special about the link terminating at the
receiving host compared to intermediate hops? I know the first link
emanating from the transmitter is special (because the packet generator
has access to the link scheduing directly), but why is the receiver link
different from any of the other links? Perhaps if you could explain this
one I could start to see what you're getting at.
 
> This smart flow-based scheduler is then likely to perform 
> some sort of implicit QoS by snooping the packets to make 
> sure they deserve this preferential treatment.  
That's not implicit. That's explicit. The QoS treatment is explicitly
encoded in the packet header by the DSCP marking in the diffserv case,
and by the session flow state instantiated by RSVP in the Intserv case.
Why do I get the feeling we're talking past each other here?

> Otherwise, 
> you just cannot be sure that such bursts will stay together, 
> unless you somehow manage to avoid sending other kinds of 
> data.  The latter sounds like putting the whole IPv6 platform 
> back on restrictions that make it resemble circuit-switched 
Where did you get that from what I said? Current practice in the IP
world is to: (a)differentiate traffic flows either by diffserv marking
or RSVP flow state, (b)schedule the links by mapping either flows or
aggregates to queues, (c)maintain packet ordering within
flows/aggregates. How does that equate to circuit-switching?

> > So, explain why
> > piggybacking wins here (again, I'm operating under the 
> assumption of 
> > no causal or temporal dependency). I would think splitting 
> the BU from 
> > the data packet would win (assuming moderate header compression 
> > efficiency) because you could mark the jitter-sensitive 
> data with EF, 
> > while letting the BU go best effort. I *must* be missing something 
> > here since my cRTP an LFI measurements on 
> bandwidth-constrained links 
> > all seem to confirm this.
> 
> Well, the way you say it here, of course I have to agree, 
> because marking jitter-sensitive data with EF amounts to 
> doing some sort of QoS signaling, and I have been trying to 
> suggest that such signaling is exactly what is needed to make 
> things work that way.  
Ah, a breakthrough! :-)

> Furthermore, I suggest that such 
> signaling should, on appropriate links, cause the packet 
> scheduler to assign the separate microflows to separate 
> channels.  Finally, it seems likely  that the initial 
> signaling (end-to-end) could cause the application to exert 
> the appropriate controls so that Binding Updates are 
> separated out if that is needed by the bandwidth manager on 
> the appropriate link.  This isn't absolutely necessary, 
> though.  I can imagine that the voice/control signaling 
> packets could be fragmented across both bearer channels for 
> even better performance.  I don't see that it is very likely 
> people would design systems that way, but they could.
> 
Gee, we already ship stuff that does this...it's called MLPPP. I think
lots of folks have it.

> 
> > My suggestion of using packet blocking at the L3/L2 interface is 
> > simply to optimize channel scheduling. This can win even on 
> relatively 
> > fast links, like DOCSIS uplinks.
> 
> I'm not at all against such things.  I only say that we don't 
> need to solve that problem in order to move forward.  That 
> would be a lot of work. We just have to agree not to break 
> basic IPv6 functionality.
> 
Why does choosing to not exploit a feature (piggybacked BU's) equate to
"breaking" IPv6?

> > > I am optimistic that we will reach consensus soon.  I 
> really think 
> > > there is an answer that will satisfy everyone's needs.
> > >

> The benefits are as previously noted:
Both of these can be achieved in other ways, as I've noted. Blocking at
the L3/L2 boundary is much more general and in fact unless you can
demonstrate that there is benefit to having the BU and the packet it is
piggybacked on getting the same QoS treatment, separating them with
different QoS marking would seem to be a much bigger win. We have some
relevant data for DOCSIS, which isn't Mobile IP packets, but may be
analogous. In the DOCSIS case, media packets go with EF, but the
ssociated control channel (RTCP) goes best effort. This wins big on
slotted channels like DOCSIS.

> - Natural processing (using already existing IPv6 code)
I'd view this as neutral, since standalone BU's are equally "natural"

>   compression/decompression engines handle separate
It would be interesting to acutally compute the numbers here, comparing
piggybacking to IPHC on consecutive packets.

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 22 Feb 2002 08:08:33 -0800

Hello Dave,

> I'll be MORE than happy to shut up.

If this happens, then I hope someone will tell me about what
kinds of messages to the list are considered appropriate.
I thought your messages were quite appropriate.

> other words, they would not be effective if sent in a different packet).

You are correct that BU is different in this way from other IP options.
However, all other options also have special features that make each
of them unique compared to all other options.  I think that BU looks
for sure like an IP option, since it controls the contents of the Binding
Cache.  It is more effective along with the payload, because it more
surely enables the "next packet" from the correspondent node to go
to the right place.  Putting the option into a separate packet does not
give the same assurance.  I don't say that sending separate packets
is completely broken.  I only say it's not as good, and that we already
have done all the work to be able to standardize the "better" approach:
specification, testing, interoperability.  There is no reason to go
backwards.

> the L3/L2 interface is equally or more effective at).

If the compression profile allows optional presence of Binding Update,
then this is a win compared to having separate compressed packets for
payload and Binding Update packets.   Of course, if the Binding Update
packet is uncompressed, then the win for piggybacking is even greater,
but that wouldn't be a fair comparison.  However, it is worth noting that
the latter is a real possibility in various implementations.

> the win for piggybacking?

On the receiving side, the difference is that it is more likely that
the correspondent node will have the "correct" care-of address at
the time it sends the "next" packet to the mobile node.

On the sending side, I think there are two reasonable ways to insert
the Binding Update:
1. At the same time that the mobile node sends a packet to the
    correspondent node.
2. In a packet which is scheduled for delivery either before or
    after (1).

In case (1), it is very likely that it's appropriate
to send the Binding Update.  In case (2), it could be that the Binding
Update didn't need to be sent at all.  I think there is a good chance
that sending the BU to all correspondent nodes in the Binding List,
if it is done as soon as the new care-of address is acquired, will
produce "too many" Binding Update packets.  This will happen at
the worst possible time -- i.e., just as a handover is completing.
I reckon that other things are likely to be happening at that time,
and we should avoid congesting the channel with perhaps untimely
control information.

To put it another way, suppose there are 10 correspondent nodes
in the Binding List.  Now let's have a handover.  The mobile node
(taking the most likely strategy) will send 10 Binding Updates as
soon as it gets the new care-of address.  This is in addition to
some other likely signaling for fast handovers, and whatever data
happens to be in progress.

This would be bad.  So, we can make things algorithmically more
complicated, in some way that so far nobody has told me about.
Or we can do the simple thing, and piggyback Binding Updates
along with natural data transmission.  Mandating randomized
delays seems clearly wrong, so that should not be chosen as a
remedy for sending out too many Binding Updates at handover time.

> are. Sorry to be so dense!

Dave, when I think of times I have discussed with you, the
word "dense" does not come to mind.

> Don't tell the diffserv guys that :-)

Isn't diffserv a way to characterize aggregated but reservable resources?

> of piggybacking versus alternatives.

People want to separate out the Binding Update so that it does not
flow along a bearer channel that is already used up.  Isn't this exactly
the same as reserving that bearer channel for the specific kind of
data they have in mind?

It affects the question, because if this reservation were not viewed
as desirable, then there would be no problem with piggybacking
(given IPv6 MTU).

> with what the QoS tradeoffs are for various traffic patterns arriving

If the link can carry IPv6 MTU, then it can carry piggybacking.

Don't you agree?

If there is some other reason that piggybacking is viewed as
undesirable, then I understand that reason to be related to QoS,
according to recent discussion.

Do you not agree?

If you agree on these two points, then please let me know what
our next point of disagreement is and I will try to harmonize.

> one I could start to see what you're getting at.

You are right that there isn't NECESSARILY any difference between
the intermediate links and the final link.  However, the receiver's link
is being viewed as bandwidth constrained and appropriate for transport
of only a single size packet.  I am opposed to allowing that
characterization
to control the protocol design, and instead I propose that such restrictions

should be enforced as a result of some QoS negotiation for that purpose.

> Why do I get the feeling we're talking past each other here?

Because I thought you were talking about the implicit case.  If you meant
to have explicit QoS control over this treatment, then I already agree with
you, and I suggest that the QoS negotiation should also trigger whatever
the desired affects are with respect to piggybacking.

> flows/aggregates. How does that equate to circuit-switching?

Please see above for some of my confusion (explicit vs. implicit).
For the rest, I claim that piggybacking Binding Update will not be
any worse than sending best effort packets along with the specially-sized
packets.  In other words, eliminating piggybacking is basically
barking up the wrong tree.

> > suggest that such signaling is exactly what is needed to make

:-)

> Gee, we already ship stuff that does this...it's called MLPPP. I think

That wasn't exactly what I was referring to, but it's not germane to
this discussion so I'll just agree with you :-!

> Why does choosing to not exploit a feature (piggybacked BU's) equate to

It is not being framed as a matter of choice.  No one has intended to
MANDATE that EVERYONE has to piggyback Binding Update.  I have
only been making this discussion so that, in systems where it is important,
we COULD use this feature if we find it to be advantageous.  We have
shown how it might be advantageous.  If you want to use Binding Update
separated out from payloads, along with IPsec, then please DO that!
I'll be delighted to enable that mode of operation.  I only wish that others

would be as generous, by the simple device of agreeing not to break this
basic IPv6 functionality.

> slotted channels like DOCSIS.

It is these slotted channels that, I assume, motivate the discussion.
And, I have no problem with allowing the kind of operation you
suggest.

However, we do NOT have to restrict Binding Update to get this,
and if there is any QoS operation at all, it should be sufficient to
enable the separation of Binding Update from payload as you may
need.  Plus there are other handy ways to achieve the separation.
But to legislate it out of existence is heavy-handed and unnecessary,
and as you seem to agree, only motivated by the characteristics of
particular link layers.

> I'd view this as neutral, since standalone BU's are equally "natural"

I hope my scenario above (with 10 possibly unnecessary Binding
Updates) would change your mind.

> piggybacking to IPHC on consecutive packets.

Perhaps my discussion about header compression earlier in this
note will provide some useful intuition.

Regards,
Charlie P.