Subject: Re: [mobile-ip] Handover Smoothing - What to Do?

From: Rajeev Koodli <[email-masked]>
Date: Thu, 26 Jul 2001 16:50:22 -0700

Hello again James,

James Kempf wrote:

> Hi Rajeev,
>
> I believe you misunderstood me. I am not advocating that smoothing be added
> to  the current FMIPv6. I think we should have smoothing be a separate item.
> I also think it should be taken  out of the low latency MIPv4 spec. There
> are some WG members I've talked to who don't believe smoothing is actually
> needed if the latency is kept low enough (for example, for BETH it will
> only be the L2 latency, no L3 latency at all). I am  not of that opinion, however,
> I think that some smoothing technique requiring perhaps both may be needed in most
> cases, but only implementation experience will really tell.
>

Ok. Glad that we are on the same page.

>
> W.r.t. buffering, there has been alot of focus on the drawbacks of bicasting.
> Things are not so golden with respect to buffering, however. As I've tried
> to mention in a couple of emails, if you buffer during handover, the latency
> propagates. When you download the buffer to the MN, you need to buffer until
> the download is finished, etc. There's no free lunch, those real time packets
> keep coming in.
>

The actual process depends however on the end-to-end network dynamics. For example,
if there is a talkspurt during handover followed by an idle time, then you could
drain the buffer without actually propagating the delay per se. You might affect the
start time of the *next* talkspurt however, in the sense that the idle time is not
exactly the same as that of the sener's. However, this is not a big deal in packet
networks with jitter buffers and smart playback adjustment.

Regards,

-Rajeev

>
> If you take that into  account, you end up getting some pretty strict bounds
> on what you can do for real time traffic. This is the discussion that
> Gary and I were having about delay budget. Buffering essentially prolongs
> the handover latency as the subsequent buffering periods are downloaded.
> There's an analysis in Appendix B of draft-kempf-beth-ipv6-01.txt if you
> care to check it

>
>                 jak
>
> >Hello James,
> >
> >
> >James Kempf wrote:
> >
> >> Hi Phil,
> >>
> >> >There does seem to be some consensus that if a smoothing technique is chosen
> >> >it should be through bicasting or simultaneous binding rather than some kind
> >> >of
> >> >buffering.  At the minimum we should have a discussion of why the tradeoff
> >> >of
> >> >accepting the possibility of duplicate packets weighs more heavily than
> >> >accepting
> >> >the possibility of lost packets and the results should be documented.
> >> >
> >>
> >> I have not heard much from advocates of buffering in the discussion
> >> so far, so I would have to agree.
> >>
> >>
> >
> >I don't understand your viewpoint. Just because you have not heard from
> >buffering advocates does not imply that the alternative is the way to go. There
> >are at least two things to consider. First, you are proposing to add a
> >particular smoothing technique to FMIPv6. I am registering my complaint saying
> >that it is not the right thing to do. FMIPv6 must be able to work independently
> >of bicasting. I have provided the problems stemming from header compression as
> >an example to illustrate the added complexity. Second, taking up smoothing as a
> >topic by itself, it is not a foregone conclusion that bicasting/simultaneous
> >binding are the only means. This is an open area and we need discussion and
> >*real experimental* evidence. Also, the header compression example hold here as
> >well.
> >
> >Regards,
> >
> >-Rajeev
> >
> >
> >
> >> >George has also asserted (and speaking for myself personally I also agree
> >> >with)
> >> >that implementations in some environments at least can solve this without
> >> >any kind
> >> >of protocol support at layer 3.
> >> >
> >>
> >> I agree also.
> >>
> >> >Does this seem to summarize everyone's position accurately?  Does this
> >> >answer your question
> >> >enough, Jim?
> >> >
> >>
> >> Yes, thanx.
> >>
> >> >Of course, others contributing to the conversation COULD help,
> >>
> >> Agree.
> >>
> >>                 jak
> >

---

From: James Kempf <[email-masked]>
Date: Thu, 26 Jul 2001 15:33:03 -0700

Hi Rajeev,

care to check it.

		jak