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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 29 Nov 2001 15:59:58 +0100

Cedric, 

First, thanks for the analysis.
Some comments on your paper. I don't think I'm 
saying anything new (others have made similar 
comments), but you didn't include some fundamental 
issues in your analysis. 

For instance:

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

- You didn't consider the case where h exceeds 
  the link layer frame capacity and the impact of that
  on the application's traffic. I would imagine that 
  link layer fragmentation would take place which 
  would add delays/service disruption. 

- I think the bottom line is that we need to make 
  sure that the packet's size does not exceed the 
  link layer frame size (in very simple terms :))
  So if you can fit 2 packets in one layer 2 frame
  (l2 piggybacking) then the same result is achieved
  (as l3 piggybacking).  
  Of course in cases where you DO have channel 
  acquisition times then piggybacking is more crucial 
  but I don't see why it can't be done on L2 anyway. 

Some other minor comments: 

- You mention that VoIP handover are typically 
  every minute ? is this an IP handover ? if so
  what's the source ?

Hesham

  > -----Original Message-----
  > From: Cedric Westphal [mailto:[email-masked]]
  > Sent: Tuesday, November 20, 2001 1:03 AM
  > To: [email-masked]
  > Subject: [mobile-ip] more about piggybacking.
  > 
  > 
  > 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.
  > 
  > 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.
  > 
  > The details will be available very soon at:
  > people.nokia.net/~rajeev/piggyback.ps
  > 
  > Cheers,
  > 
  > Cedric.
  >

---

From: Cedric Westphal <[email-masked]>
Date: Thu, 29 Nov 2001 08:12:18 -0800

Hesham,

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

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

>   would add delays/service disruption.

You are right.  I tried to keep it simple, and not to get into some
specific L2 issues.

>   (l2 piggybacking) then the same result is achieved

I agree with you on this too. But keep in mind this shoehorn principle: the
smaller the
size of what you are trying to fit in one L2, the better the chance
you'll succeed earlier. So if you try to fit one payload + one BU,
vs. one payload with pb'ed BU, you will finish first with the latter option
in
most situations.

>   every minute ? is this an IP handover ? if so

I had some order of magnitude in mind from cellular networks.
Take care,

Cedric.

---

From: Gerald Maguire <[email-masked]>
Date: Thu, 29 Nov 2001 18:14:59 +0100 (MET)

Cedric Westphal <[email-masked]> said:
    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.

But there is a relatively straight forward solution, put the BU just
_after_ the voice packet, then you don't add jitter. Since you know
there will _not_ be another voice packet for 10-20ms (depending on
packetizing, coding, silence supression etc.) as long as you can send
the BU is less than this time you will not add to the jitter of the
series of voice packets.

This is not particularily more difficult that the technique long used
for SLIP to recognize port numbers and packet size and handle
interactive traffic differently from (i.e., ahead of) bulk transfer.

Chip