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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 13 Feb 2002 17:56:14 +0100

Charlie, 

This is not an attempt to start another
long thread about the benefits of piggybacking
but I would like make a couple of points that
I think might help:

1. Since the current recommendation seems to be:
   Mandate RR and optionally CGA on top later. 
   And since it is recommended that RR does not
   setup a BSA, where is the issue of piggybacking
   if you use RR only? 
   Something like BU3WAY runs the entire protocol
   on ICMP, so you can't piggyback these meesages
   anyway. Where is the issue?

2. So far we've seen a concrete paper from Cedric
   and yourself which upon discussion didn't not 
   result in any significant advantage of piggybacking
   the BU (please refer to the archives, thread:
   'more on piggybacking'). So I really don't see 
   why you're against this decision.

These are the 2 main comments. I have a couple
of specific ones below.

  > That is a very important point.  Regarding the "asserted"
  > benefits, I think it can be shown that piggybacking _always_
  > offers performance benefits to a compliant IPv6 implementation,
  > and that sometimes the benefits would enable important
  > applications (like voice) to work better.

=> Interesting, because I can negate the exact
argument with examples. But the paper which
you co-authored essentially concluded that:
- 'Don't go to war over BW efficiency
  of piggybacking'.
- Piggybacking is good to reduce jitter during
  a handover.

Upon discussing the second point in the thread
I mentioned, we saw that certain assumptions
were made regarding the link layer configuration
(of a cellular link) that were not accurate
(please refer to the thread).
So I'm still not sure about what the benefits
are.

  > >         - in cases where the functionality is detrimental
  > >           on certain kinds of links, the receiver may be
  > >           victimized when sent a piggybacked BU
  > 
  > There are not any such links that correctly implement IPv6
  > MTU.  

=> What does this mean?? There are no link layers
that follow RFC2460?

  > The complete answer about how to use IPsec is going to take more
  > effort than we can muster in the near term.  Such effort SHOULD
  > take into account the particular needs of Mobile IPv6 BSAs,
  > anyway.  I think that we should NOT go back to using only AH,
  > especially because AH itself is likely to be deprecated in
  > the future.  

=> I don't think the comment was related to securing
BUs with IPsec, but simply _using_ IPsec. Surely
we can't leave that out.

Hesham

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 13 Feb 2002 09:35:39 -0800

Hesham,

since you include me in this discussion...

>   why you're against this decision.
The paper results in significant advantage of piggybacking with respect 
to jitter.
I went back to the thread, and could not see any argument disproving this.
Your point in the thread was (I rephrase quickly, but go to
http://www.atm.tut.fi/list-archive/mobile-ip/thrd6.html#01722 for the 
details):
Hesham: 'oh, but BU and data do not necessarily share the same medium, so
BU don't introduce jitter'. To which I responded that: 'but dear, what 
if they do'.

To sum it up, of course, if you chose the right situation (avaibility of 
a control plane
and a user plane, like you suggested in the thread), then there is no 
jitter benefit (I even
have a better situation with absolutely no benefit from piggybacking: 
prohibit the
mobile node from moving :-) But the IETF is not here to design for the 
convenient
link layer. The purpose should be to design the best solution, and 
piggybacking
always reduces bandwidth and improves jitter, the latter often in a very
significant way.

Regards,

Cedric.

>(please refer to the thread).
please read my comments above.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 13 Feb 2002 10:19:54 -0800

Hello Hesham,

I'll try to avoid repeating what others are saying, but
perhaps without complete success.

>    setup a BSA, where is the issue of piggybacking

We have to allow for situations where mobile node
and correspondent node already have an appropriate
security association, created by whatever means.
RR is proposed as a scalable solution that can support
billions of nodes.  I would be very opposed to any
attempt to shape every other bit of protocol around
this interim solution.

>    anyway. Where is the issue?

This is totally irrelevant to what happens when you
already have an established security association that
enables use of Binding Update with payload.

>    why you're against this decision.

Cedric has responded to this, but I wish you would
not so blithely brush aside this work.

> argument with examples.

If so, then I will be able to show that your examples
are not IPv6 compliant.

> So I'm still not sure about what the benefits

I don't have the thread handy, but I do not recall
any such inaccurate assumptions.

> => What does this mean?? There are no link layers

Of course it does not mean that.  It means that link layers are
required to handle MTU >= 1280, and Binding Updates with
average payloads fit well within that requirement.  I cannot
imagine how you might have constructed the interpretation in
your second sentence.

> BUs with IPsec, but simply _using_ IPsec. Surely

You can use IPsec, and if you do you might wish to avoid
having payload, in order to avoid the problems that have
been raised.  I can use Binding Authentication Data suboption,
and have payload.  Compliant IPv6 implementations can
receive both.  I do not see any problem here with allowing
piggybacking.  Everyone can be happy.  Thus, I am at a loss
to figure out why you are not happy.

Regards,
Charlie P.