Subject: RE: [mobile-ip] more about piggybacking.

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Tue, 20 Nov 2001 13:05:11 -0600

Cedric,

The tone of this email was not warranted. Please refrain
from sending inflammatory emails to the list. The WG
discussion list is for technical discussions only. I keep
having to emphasize this every so often, that it is getting
quite repetitive.

-Basavaraj

> -----Original Message-----
> From: ext Cedric Westphal 
> Sent: Tuesday, November 20, 2001 12:38 PM
> To: [email-masked]
> Subject: Re: [mobile-ip] more about piggybacking.
> 
> 
> Mike,
> 
> please read the document before you comment the teaser.
> Your mom  never told you not to judge a movie by its trailer?
> 
> Cedric.
> 
> Michael Thomas wrote:
> 
> > Cedric Westphal writes:
> >  > Hi,
> >  >
> >  > there was an intense debate a couple weeks ago over the merits of
> >  > piggybacking. So we put together a little bit of 
> analysis to bring the
> >  > discussion on less intuitive and more mathematical grounds.
> >  >
> >  > The outcome of it is dual:
> >  > - The percentage improvement in bandwidth utilization is 
> typically
> >  >    small.
> >  > - The percentage improvement in jitter during handover 
> is typically
> >  >    large - actually, very large.
> >
> >    The problem here is that for things that are
> >    jitter sensitive, binding updates piggybacked
> >    or not are going to be inadequate in all but
> >    the most contrived laboratory settings. Speed
> >    of light, etc, mean that you need FMIP for fast
> >    convergence of the move, thus taking the long
> >    haul binding update out of the critical path.
> 
> That's not the point of the debate we had. I thought you 
> participated...
> 
> >
> >
> >  > This basically says that piggybacking will not allow a 
> provider to squeeze
> >  > more people on the same link, but that by not having 
> piggybacking, the
> >  > user gets a significantly worst QoS.
> >
> >    This presupposes that:
> >
> >    1) jitter is important across the board
> >    2) that piggybacking is the only impediment
> >       to getting jitter sensitive traffic
> >       delivered within the proper bounds.
> >
> >    Neither of these are true.
> 
> 1) Right, jitter is not important in a VoIP call. Have you 
> heard of real time
> applications? Duh.
> 2) Says who? YOU ONLY decided to add ONLY in presupposition 
> 2). Of course,
> pb is not the ONLY impediment. Piggybacking is not the 
> solution to ALL problems.
> Now, if you use piggybacking, you ALWAYS get an improvement 
> for jitter sensitive
> traffic. Because other factors in the network will add jitter 
> as well, does this
> mean that
> you should not use piggybacking. It's like saying: don't wear 
> a seatbelt, as it
> is _not_ the _only_ implement
> (oh my god, where did you fish 'impediment': piggyback does 
> not obstruct timely
> delivery
> of jitter sensitive traffic, au contraire, mon frere) 
> preventing death is car
> crashes.
> 
> Neither of your point makes any sense.
> 
> Cedric.
> 
> >
> >
> >            Mike
>

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 20 Nov 2001 12:07:17 -0800

Murat,

"Bilgic, Murat" wrote:

> Cedric,
>
> What's the assumption behind having a single link?

piggybacking is usually considered for the last hop, the last link between
the network and a mobile user. That's why we consider only this link. We
considered the saved bandwidth on this (single) link, as it is also the
bandwidth
constrained link. We considered the delay created on this link.
The assumption is here that it gives you a lower bound on the jitter, as more
delay is already added in the network.

>
> What's the delay tolerance of the BU?

This is not for me to answer, I do not know.

>
> What is the impediment against having an on-demand link for BU only,
> especially since all the factors you cite will reduce the amount of BU
> traffic?

I don't think there is any, besides some implementation complexity.
Thanks,

cedric.

> Thanks,
> Murat
> From: Cedric Westphal [mailto:[email-masked]]
> Sent: Monday, November 19, 2001 4:03 PM
> Subject: [mobile-ip] more about piggybacking.
>
> Hi,
>
> piggybacking. So we put together a little bit of analysis to bring the
> - The percentage improvement in bandwidth utilization is typically
>    small.
> - The percentage improvement in jitter during handover is typically
> This basically says that piggybacking will not allow a provider to squeeze
> more people on the same link, but that by not having piggybacking, the
> The details will be available very soon at:
> people.nokia.net/~rajeev/piggyback.ps
>
> Cheers,
>
> Cedric.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 29 Nov 2001 18:10:08 +0100

Cedric, 

  > 
  > thanks for reading it. Let me say here that the purpose of 
  > the document
  > was not to be exhaustive. Comments in line.
  > 

=> Sure. I still found it quite useful though.

  > > - You assume that the BU should share the same channel
  > >   as the connection traffic. This on its own will add
  > >   to jitter (whether you piggyback or not). So I think
  > >   you definitely want to have a separate channel for the
  > >   BU, especially on links with QoS assurances. The reason
  > >   is that I believe you may need different channel characteristics
  > >   (configuration) for your signalling when compared to
  > >   your payload. One example is reliability and there
  > >   are more.
  > >   So IMHO the cleanest way to use MIPv6 on these links
  > >   (low BW, QoS assurances ....basically cellular !) is
  > >   to assign separate channels for IP signalling.
  > >   This would eliminate the jitter due to BUs.
  > 
  > I agree with you that separating BUs from voice packet 
  > would eliminate
  > jitter
  > for voice packet. On the other hand, usually in an IP 
  > world, you don't have
  > 
  > that luxury of separating the cellular world's user plane 
  > and control
  > plane.
  > 

=> Well, a device made to work on a cellular link
should be able to map IP packets to certain channels. 
You can use some internal tagging between IP and L2.

But anyway, the more important point is that it can 
actually be quite harmful to piggyback two different
contents (requiring two different radio configurations)
on the same channel. Take your example for instance, 
a VoIP connection, the way the channel might be configured
here might be too unreliable for IP signalling where 
you would want a reliable channel. This is just as 
important as the points below. 

Cheers,
Hesham