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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 15 Feb 2002 16:39:09 +0100

> 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.
  > 
  > 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.

=> Provided the payload's needs are known.
If part of the payload requires different
treatment from the rest, then it doesn't
make any sense to include both in the 
same IP packet. 

  > 
  > > Hence placing 2 different sets of information (each
  > > requiring a different treatment) in one
  > > 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.

=> ?? I realise that IP requires handling 
at the IP layer. When you say 'the way things
are now', are you referring to MIPv6 or 
IP in general?

  > 
  > > 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.
  > 
  > 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 -- 

=> Agreed.

including
  > the management of control signals, as well as
  > various kinds of payloads.  

=> Sure, but 'various kinds of payloads' in various
packets is fine, whereas 'various kinds of payloads'
in the same packet is not good.
Can you give me a concrete example about how 
this can be handled in terms of doing the 
'right thing' for each of the different types
of payload, at the same time ?
Even if there is such example (I don't know if
there is), the point is, this is a bad protocol
architecture.

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.

=> Of course, but this is not the point. If one packet
contains a BU (requires channel configuration X) and 
another application payload (requires channel config Y). 
I don't see a trivial way of selecting a single
channel for this single packet.

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

=> i must have missed something above, because
I don't know how you reached that conclusion.

  > 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, 

=> The payload size is not the big issue here. 

but ALL IPv6 link-layers
  > have to be able to do that.  

=> They sure do, but for a price: additional
significant delays.

Hesham

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 15 Feb 2002 09:03:26 -0800

> make any sense to include both in the

The payload has its needs.  Specific needs for the
Binding Update are met by using the Binding Authentication
Data suboption.

> are now', are you referring to MIPv6 or

I am referring to Mobile IPv6.  But it's also true for IPv6 :-)

> of payload, at the same time ?

I don't know what "this" is, but:

- Binding Authentication Data suboption can always be
  used to authenticate Binding Updates.
- IPsec AH can be used, with special handling and key
  negotiation, to authenticate Binding Updates if there
  is no payload.

that is, assuming we get the spec out before they invalidate
use of AH.

> there is), the point is, this is a bad protocol

I strongly disagree with this characterization, and I
am ever more certain that you cannot support it.

> channel for this single packet.

You can't put a round peg in a square hole of equal area.
If this point is not clear, after all I have written about
it, then let me know and I will try again.  To summarize,
if your application has particular QoS requirements,
then it is easy to make the QoS negotiation satisfy those
requirements.  To reduce performance on ALL link
layers, especially if it is because of unwillingness to
allow your particular link-layer to follow IPv6 requirements,
is not legitimate.

> I don't know how you reached that conclusion.

Do you see now?

> => They sure do, but for a price: additional

Again, this is simply not correct.  The additional delay
only happens for link layers which SHOULD do the
appropriate negotiation, but fail to do so.  Their only
remedy is to enforce their QoS requirements on every
other link layer.

Not fair!

Regards,
Charlie P.