Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 6 Jun 2001 12:23:00 -0500

Yes, I was off by 1^3. BAD mistake for an
ex physical layer guy :)

Madjid

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Tuesday, June 05, 2001 5:14 PM
To: [email-masked]
Cc: [email-masked]'
Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff

Er Madjid, my physics book sez that c ~= 3x10^8
m/s.  that makes a km about 1/3x10^5 (in vacuum)
so even allowing for wire/fiber, you seem to be
off by a couple of orders of magnitude.

	   Mike

Nakhjiri Madjid-MNAKHJI1 writes:
 > James,
 > 
 > Thanks for sending the analysis and sorry for my late response,
 > I am still catching up with the list. The analysis made me
 > go and read the new version of the draft! So now I am even more
 > behind on the list, sorry if there has been more exchange on this.
 > 
 > I have one question and a few comments.
 > 
 > First, shouldn't you include the propagation delay from the oldAR to
 > the MN and back into the calculation?
 > Speed of light is 1 ns/foot=3ns/meter=3ms/km, so
 > in a CDMA cell of about 3Km in radius, you have 10 ms
 > propagation delay in each direction, which mean 20 ms total.
 > 
 > Also, I don't know what WCDMA does these days, but don't they add
 > some padding to the layer 3 signal (maybe that is not too big :) )
 > 
 > Now, my question isn't HI/HACK between oldAR/ newAR included in stateful
 > case, aren't
 > those messages in critical path? I saw your comment about Mobile
 > determined case (that HI/HACK should be included). Doesn't the same 
 > apply to Network determined stateful?
 > 
 > Again the HI/HACK has both transmission delay and propagation delay.
 > 
 > Thanks,
 > Madjid Nakhjiri
 > 
 > -----Original Message-----
 > From: James Kempf [mailto:[email-masked]]
 > Sent: Monday, May 14, 2001 4:40 PM
 > To: [email-masked]
 > Subject: [mobile-ip] Times for Low-Latency IPv6 Handoff
 > 
 > 
 > As an interesting exercise, I went through some calculations about how
 > long an IPv6 low latency handoff would take in some of the scenerios
 > described in draft-ietf-mobileip-fast-mipv6-01.txt. I looked at the
 > following cases:
 > 
 > 	- Network determined, stateless with the following two subcases:
 > 		- F-BU/F-BACK received before handoff 
 > 		- F-BU/F-BACK received after handoff  
 > 		
 > 	- Network deterimed, stateful 
 > 	
 > 	- Mobile determined, with the following two subcases:
 > 		- F-BU/F-BACK received before handoff
 > 		- F-BU/F-BACK received after handoff
 > 		
 > I also made the following assumptions:
 > 
 > 	- Prior to handoff, the header compressor on the old AR is
 > 	"hot" enough to compress the basic 40 byte IPv6 header down
 > 	to 1 byte, but after handoff, the header compressor is "cold"
 > 	and so the full IPv6 header needs to be sent. Currently, there
 > 	is some debate about whether the compressor could be partially
 > 	restarted on the new AR using context transfer, so this could
 > 	introduce an additional optimization and also a potential 
 > 	area of timing uncertainty involving the context transfer
 > 	time itself.
 > 	
 > 	- The BU/BACK pair completes on either side of the handoff.
 > 	In actuality, it may span the handoff and Section 3.3 may
 > 	come into play if the MN doesn't get a BACK back (so to
 > 	speak) fast enough. Or, an additional BU may need to be sent.
 > 	I view the assumptions made here as being fairly optimistic,
 > 	since over the air signalling after L2 has indicated that
 > 	handover is pending is likely to be subject to a considerably
 > 	higher error rate due to deteriorating radio conditions in
 > 	the old cell and not-yet improved radio conditions in the new.
 > 	
 > 	- The radio link layer is using its lowest bit rate for signalling.
 > 	This assumption is based on either using a multiplexed common
 > 	channel for signalling, in which case the MN would have to share
 > 	the channel with other MNs in the cell, or using a dedicated
 > 	channel but not wanting to charge the user much or nothing at
 > 	all, and therefore not wanting to use a higher bandwidth. Of
 > 	course, this will be radio-specific, but it seems like a good
 > 	assumption for cellular systems. The value I used was 7.5 kbps
 > 	(940 bytes/sec), which is the minimum for a wCDMA dedicated channel
 > 	from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000.
 > 	
 > 	- The wired link ARs use Ethernet (48 bit MAC address link
 > 	layer) and the wireless link is using 15 byte IMSIs (International 
 > 	Mobile Station Identifiers) sent as ASCII digits.
 > 	
 > 	- The MN can neither send or receive traffic on the new AR until
 > 	the old AR has confirmed the new CoA via a F-BACK. 
 > 	
 > Here's the results.
 > 
 > Network Determined, Stateless
 > -----------------------------
 > 
 > As near as I can tell, the following messages get exchanged over the
 > air: PrRtAdv, F-BU, F-BACK.
 > 
 > Sizes of these are:
 > 
 >             hdr   msg   lnkAddrOpt   prxLnkAddrOpt   newCoA	Total
 > 	
 > PrRtAdv      1     8        9             9            24         51
 > 
 > F-BU 
 > before       1    10						  11
 > 
 > F-BU
 > after        40   10						  50
 > 
 > F-BACK
 > before       1	   9						  10
 > 
 > F-BACK
 > after        40    9					          49
 > 
 > Total over the air sizes:
 > 
 > F-BU/F-BACK before: 51 + 11 + 10 = 72 bytes
 > F-BU/F-BACK after:  51 + 50 + 49 = 150 bytes
 > 
 > Times:
 > 
 > F-BU/F-BACK before: 72 bytes / 940 bytes/sec = 0.077 sec = 77 msec.
 > F-BU/F-BACK after:  150 bytes/ 940 bytes/sec = 0.160 sec = 160 msec.
 > 
 > However, total handoff time will consist of the above plus a
 > nondeterministic amount of time involved in L2 handoff and the
 > amount of processing time required on new AR to perform DAD and 
 > process the HI/HACK pair. Perhaps one could use the maximum
 > of L2 handover time and HI/HACK processing time as an estimate
 > to add to the above.
 > 
 > Network Determined, Stateful
 > ----------------------------
 > 
 > Messages exchanged over the air- PrRtAdv prior to handoff.
 > 
 > Byte counts the same as the above. No F-BU/F-BACK needed, so the
 > only over the air message required is the PrRtAdv.
 > 
 > Total over the air size:
 > 
 > PrRtAdv size: 51 bytes
 > 
 > Time:
 > 
 > 51 bytes/ 940 bytes/sec = 0.054 sec = 54 msec.
 > 
 > L2 handover time needs to be added.
 > 
 > Mobile Determined
 > -----------------
 > 
 > Messages exchanged over the air: RtSolPr, PrRtAdv, F-BU, F-BACK.
 > 
 > Byte counts for PrRtAdv and F-BU/F-BACK the same as above. RtSolPr
 > sent by MN is done prior to L2 handoff.
 > 
 >            hdr    RtSolPr     MNlnkAddrOpt     newAttPtLnkOpt      Total
 >       
 > RtSolPr     1       8              18                9               36
 > 
 > Total over the air sizes:
 > 
 > F-BU/F-BACK before: 36 + 51 + 18 + 10 = 115 bytes
 > F-BU/F-BACK after:  36 + 51 + 50 + 49 = 186 bytes
 > 
 > Times:
 > 
 > F-BU/F-BACK before: 115 bytes/ 940 bytes/sec. = 0.122 sec = 122 ms
 > F-BU/F-BACK after:  198 bytes/ 940 bytes/sec. = 0.198 sec = 198 ms
 > 
 > Again, the maximum of L2 handoff time and HI/HACK processing time
 > would need to be included.
 > 
 > Conclusions
 > -----------
 > 
 > What conclusions to draw? These time range from respectible (55 ms
 > for network determined, stateful) to the clearly questionable (198 ms for 
 > mobile determined, F-BU/F-BACK sent after). The ITU recommends 300 ms
 > maximum for delay before the user notices with real time voice traffic. 
 > Depending on the amount of time required for the L2 handover, the HI/HACK 
 > processing time, and any time required to send buffered traffic to
 > the MN if buffering is used on the old AR, the mobile determined,
 > F-BU/F-BACK
 > sent after case could easily exceed the ITU guideline, as almost 2/3 
 > of the noticable delay time is taken up by the L3 handoff. The others
 > require less L3 handoff time, but only the network determined, stateless,
 > F-BU/F-BACK before and the network determined, stateful are less than
 > or equal to about 1/4 of the ITU guideline. 
 > 
 > Clearly, header compression on the new AR could help a lot. IPv6 headers
 > are big, and if there were some way the header compressors on MN and new AR
 > could be jump started prior to handoff, the 40 byte header overhead could be
 > eliminated. Alternatively, if the link layer can guarantee that
 > the F-BU/F-BACK occurs before the L2 handoff, the header overhead won't
 > occur. Using a higher bandwidth channel could help also.
 > 
 > Please send any comments or corrections (in case my math is wrong).
 > 
 > 		jak
 > 
 > 
 >

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 6 Jun 2001 12:21:41 -0500

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, June 05, 2001 4:51 PM
To: [email-masked]; [email-masked]; Madjid.Nakhjiri
Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff

>propagation delay in each direction, which mean 20 ms total.

I assume that is built into the user level bit rate figures Holma
and Toskala give for WCDMA.

MN>> ops, I saw the mistake (I guess I have been reading too
many drafts for too long :) ) thanks Art for the slap, and Mike
it should read 

Speed of light is 1 ns/foot=3ns/meter=3us/km, so it comes down
to 20 micro sec, which is negligible.
However, not knowing the channeling of WCDMA,  it is still kind of 
odd that 7.5 kbps comes down to only 940 bytes/ sec.

>some padding to the layer 3 signal (maybe that is not too big :) )

Typically, radio frames are much smaller than IP packets (on the
order of 40 bytes). It is possible that there may be padding
if a packet won't fit into an even number of frames, but, again,
I was using the user level throughput figures.

MN>>Well, yes you do need to do L2 segmentation to fit the size
of L2 frames, but what I meant was the L2 headers that will
be added to each frames and the channel coding that L2 does,
and those add up the bytes that you calculated, but as you said maybe
these are all baked into the 7.5 kbps to 940 bytes/sec
conversion!

>Again the HI/HACK has both transmission delay and propagation delay.

Signalling across the wired backbone is typically less than 10 ms. 
I believe I calculated something in the submillisecond range for
T1 on the HI/HACK. So it's basically in the noise, as far as
the radio link is concerned.

MN>> thanks, it makes sense.

Madjid