Re: comments on draft-park-pppext-mip6-co

I have a few observations.

First, I'd like to comment on Bernard's RTT numbers.
The numbers you cite are quite realistic for some
systems and for GPRS in particular. However, we are
also seeing significantly different numbers, particularly
with vendors who have paid a lot of attention to RTT :-)
and especially with UMTS. I don't want to go to the
specifics, but we are talking about an order of
magnitude or larger difference to your numbers.
Less than my current RTT with your server, for instance.
I do agree that with your numbers, there is a lot of
things that work very badly if at all.

Secondly, I'd like to comment on the general applicability
of network attachment optimizations:

- Regardless of the RTT (but it has to be usable!),
   these optimizations _can_ make a lot of sense.
   This is because in many cases the L2 establishment/
   network access control/authentication/router discovery/
   address assignment tasks are on the critical path,
   and packets are being lost or delayed meanwhile.
   Even with a fast RTT, this can have an effect in
   some real-time applications.

   Even a single roundtrip *can* count. But then you
   have to make a believable case about the overall
   system delays, including all messaging involved
   in the different layers. The overall system delays
   are decreasing, however, as most if not all delay
   aspects involved in network attachment are being
   optimized in some forum or the other.

- In addition to speeding up the attachment process,
   there are also alternative schemes that reduce
   reliance on the attachment. Local mobility schemes
   can help recover after an attachment, as long as
   the delays caused by the attachment are not _too_
   great.

   Another approach is to avoid repeated attachments.
   For instance, in general it makes more sense to keep
   the GPRS/UMTS PDP context active all the time rather
   than to bring it up down every time one encounters
   an alternative (e.g., WLAN) network access.

   (Park's draft seems to focus on CDMA2k networks,
   however. I'm not sure these alternatives are suitable
   in that context.)

These are general comments on optimizations, not
specifically targetted to Park's draft. After a quick
read of the draft, it seems to me that it provides
a different way to assign addresses on a PPPv6 link;
I'm not sure what it has to do with Mobile IPv6 per
se. In any case, a system-level delay analysis and a
"why it matters" section appears to be missing from
the draft. Also, I'm not sure I understood the
claim in Sect 3 that this method eliminates the need for
movement detection process. It seems that the use of
PPP alone already provides that in some sense.

--Jari

_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext