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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 15 Feb 2002 12:40:29 +0100

> Nobody has brought up any new points (well, except perhaps 
  > Kempf's point
  > about i-mode using something akin to piggybacking but I don't know
  > if that is a link-layer type thing or an e2e thing) this 
  > time around.
  > 
  > Thus there is no more light shining on the issue than there was
  > after the last round of discussions.

=> Can't disagree with that. I'd like to summarise
my point(s) in a simple way though: 
Carrying two different types of information in
a single IP packet is (architecturally) not a good 
idea. This is due to the fact that IP packets receive 
different treatments by link layers, routers and
end hosts, depending on the content of the packet. 
Hence placing 2 different sets of information (each 
requiring a different treatment) in one 
packet is likely to break some policies. 
We've seen some examples already: IPsec and 
L2s with Qos assurances. We could also see
more in future. So the point is, the foundation 
for this idea is not correct. 

RFC2460 doesn't say anything about this, 
but I wouldn't expect it to. I think it's 
up to us to realise this. 

I hope this helps the discussion.

Hesham

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 15 Feb 2002 07:18:46 -0800

Hello Hesham,

I have considered for a long time the scenario that you mention,
and I think it can be clearly shown to be amenable to proper
architectural understanding.  That is what I'll try again to show
in this note.

"Hesham Soliman (ERA)" wrote:

>   =>   ...

Carrying IP information in an IP packet is architecturally
a very good idea.  And, IP packets are designed to have
payload.  So, carrying payload along with IP information
in an IP packet is still a very good idea.

> packet is likely to break some policies.

IP information requires handling at the IP layer,
and we already have a complete specification for
that.  I don't think you can show any broken policies
with the way things are now.

> for this idea is not correct.

This business about QoS is very interesting, and
deserves attention.  In fact, it is very reasonable
for QoS negotiation to make restrictions about
how IP-level resources are to be used.  Thus,
any QoS negotiation should have something to
say about how the channel is used -- including
the management of control signals, as well as
various kinds of payloads.  Speaking concretely,
any QoS negotiation should trivially be able to
configure transmission of Binding Updates according
to the needs of the particular link-layer that you are
concerned with.

Seen in this way, which I suggest is architecturally
much more sound, the problem just goes away
naturally.

Furthermore, seen in this way, perhaps you can
understand why I think you are putting the cart
before the horse.  You seem to claim that my preferred
design is tailored only for those link layers that can
handle certain size payloads, but ALL IPv6 link-layers
have to be able to do that.  I believe I have shown that
for the specialized needs of certain applications
(NOTE -- NOT LINKS!), QoS mechanisms are
already necessary, and can do what you need to
have done.

> I hope this helps the discussion.

I hope you will really try to see my point of view,
which is purely made from the the network layer and
the desire to maintain improved performance.

Regards,
Charlie P.