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

From: James Kempf <[email-masked]>
Date: Mon, 23 Jul 2001 10:03:18 -0700 (PDT)

I'd like to kick off a thread about how the MIP WG should
specify/document handover smoothing. There has been specific comment
around Hesham and Karim's draft draft-elmalki-mobileip-bicasting-v6-00.txt, but 
the issue is somewhat broader, since currently the IDs dealing with handover 
issues have a considerably different approach to how handover smoothing is
documented. Here are the current approaches;

	- Include handover smoothing as part of the specification of handover.
	This approach is used by
	draft-ietf-mobileip-lowlatency-handoffs-ipv4-00.txt and
	draft-ietf-kempf-beth-ipv6-00.txt, the former in the
	body of the spec, the latter primarily in an appendix.
	
	- Completely exclude any discussion of handover smoothing
	as part of the specification, even in an appendix. This
	approach is used by draft-ietf-mobileip-fast-mipv6-01.txt.
	
	- Document handover smoothing itself in a separate ID.
	This approach is used by draft-elmalki-mobileip-bicasting-v6-00.txt
	and draft-krishnamurthi-mobileip-buffer6-01.txt.
	
While consistency is not required, it is usually more helpful to readers
to have a consistent set of specifications. In addition, there are
some common threads between IPv4 and IPv6 (the analysis in the
appendix of draft-ietf-kempf-beth-ipv6-00.txt for example is independent
of IP version) and it might be possible to find more if we developed
a consistent approach to documenting handover smoothing technologies.

Here's my take on the possibilities for a more consistent approach:

	1) Include IP version specific aspects of handover smoothing
	along with the fast/low latency handover specifications. 
	This would result in folding draft-krishnamurthi... and
	draft-elmalki... into the FMIPv6 draft. We would also
	need to add something about buffering to the low latency
	MIPv4 draft, since it currently just discusses bicasting. 
	IP version independent discussions of handover
	smoothing could be included in a separate draft, like
	for example, draft-kempf..., sort of like a BCP (but, as
	yet, there is no current practice in this area, so maybe
	RFP, "recommended future practice" :-).
	
	2) Have separate drafts describing handover smoothing for
	the two IP versions, but merge the two techniques into
	one draft. Again, non-version specific discussion would
	be in a separate draft as well.
	
	3) Have separate drafts describing the two smoothing techniques
	for each IP version, and the non-version specific discussion
	in a separate draft.
	
	4) Merge all the handover smoothing drafts into one, including
	material from the version specific and non-version specific drafts,
	but keep it separate from the actual handover specification.

The document count for each of these options is:

	1) 3, one FMIPv6, one low latency MIPv4, one version independent
	smoothing draft.
	
	2) 5, one FMIPv6, one smoothing v6, one low latency MIPv4,
	one smoothing v4, one version independent smoothing.
	
	3) 7, one FMIPv6, one bicasting v6, one buffering v6, one
	low latency MIPv4, one bicasting v4, one buffering v4 (?),
	and one version independent smoothing.
	
	4) 3, one FMIPv6, one low latency MIPv4, one smoothing draft
	with version dependent and version independent.
	
Have I missed anything?

Comments? Does anybody think we might find it easier to come to
a decision if we could agree to use handoff v.s. handover and fast
v.s. low latency? :-)

		jak

---

From: [email-masked]
Date: Mon, 23 Jul 2001 13:48:31 -0500

James,

Smooth handoffs is important for certain types of applications
only, but the goal of the current handoff work in the Mobile IP WG is
primarily on fast handoff (I hope we do not get into arguments on
terminology here). 
I believe it is better to deal with smoothing of handoffs as a
separate work item/milestone. We also need to let the bicasting and
buffering drafts get some more discussion and input, as individual
I-Ds before trying to combine them. 
The current WG handoff specs (lowlatency & fast) should not focus on
this aspect of handoffs.

And I do not believe the logistics of the number of specs that would
be created has much bearing within the context of the handover work.
The same people who are interested in this work would still be
interested
whether there are 5 or 7 drafts.

-Basavaraj

---

From: James Kempf <[email-masked]>
Date: Mon, 23 Jul 2001 16:04:55 -0700 (PDT)

Hi Raj,

>The current WG handoff specs (lowlatency & fast) should not focus on

Do you think it would be best to remove the discussion of bicasting
in the low latency MIPv4 draft? Currently, the draft does not
discuss how to do bicasting, it just states that bicasting should
be used for handover smoothing, as opposed to buffering.

		jak

---

From: [email-masked]
Date: Mon, 23 Jul 2001 22:53:46 -0500

Hi James,

>be used for handover smoothing, as opposed to buffering.

What value does the discussion on bicasting add to the low latency
MIPv4 draft? I would recommend removing it and focusing on smoothing
of handoffs in a separate I-D. Handoff smoothing can also be achieved
by buffering. So why recommend only bicasting as the mechanism for the
desired effect? I do not believe there has been any real consensus of
going one way vs the other.

-Basavaraj

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Tue, 24 Jul 2001 11:53:01 +0200

Hello Raj and James

> MIPv4 draft? 

Without bicasting (or some alternative) the low latency draft is not
complete. That is, someone implementing it will find that a certain period
of service disruption will most likely be introduced by the low latency
mechanism. There will be a time difference between the moment in
which the MN sends an "anticipated" Registration to the nFA (PRE-REG) or
the H'off Req/Reply are sent between nFA-oFA in anticipation of the handoff
(POST-REG) and the moment in which the MN actually completes the L2 handoff
to nFA. This means that there is no knowledge at L3 as to where the MN is
exactly during that period and when it will make the L2 handoff, so packets
will be sent to nFA while the MN is actually still at oFA. For the duration
of this L3-handoff "anticipation" period (period shortly after the trigger
and until the MN's L2 movement) the MN could be unable to communicate. However,
the whole purpose of the low latency draft is to reduce and possibly eliminate
the period of service disruption due to handoff. So if we take bicasting
out we haven't solved the problem we aimed to solve.

>I would recommend removing it and focusing on smoothing

There has been consensus among the design team members and up to now
we have not received negative comments on the low latency draft nor during
the IETF presentations. I would be happy to consider buffering as an
alternative and eventually add it into the draft if the authors/WG want this,
but all the methods must satisfy the requirement of eliminating the period of
service disruption due to L3 handoff independently of the L2 characteristics.
Without this IMO the draft would not serve its purpose.

Regards
/Karim

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Tue, 24 Jul 2001 17:06:35 +0200

Hi George
 
> Note that there has been work towards eliminating this well 
> known problem
> and Karim can point the list to this work since I do not 
> remember that draft
> name. Nevertheless, the FMIPv6 team decided that bicasting 
> has experimental
> nature and the TCP fix was at the time a draft at v00...early 
> days => not
> enough practical experiance or understanding of what a 
> possiby wide spread
> use of bicasting do to TCP. For all the above we thought that 
> bicasting
> should be discussed as a separate item and the FMIPv6 spec 
> should not be
> dependant on it. The fact that the FMIPv4 team did not take the same
> decision always concerned me a bit...

The TCP issue is discussed with reference (EIFEL algorithm for TCP)
in the bicasting draft.

Also, for the scenarios we consider in low-latency, the MN will not
get multiple copies of packets. The "second" copy gets discarded by the
non-connected FA (e.g. nFA) and an ICMP error is not transmitted.
Alternatively that second copy may be buffered. When the MN connects to
nFA it no longer receives from oFA. That's what the draft specifies and
I think that should be quite typical for a single-interfaced MN.
So that's why we went for this solution and allowed bicasting.
The TCP issues should not be involved.

> 
> IMO smoothing (bicasting and/or buffering) should be separate 
> specs from the
> FMIPv4/v6 not only because of the uncertainty regarding 
> bicasting but also
> because (again IMO) smooth handoffs may be achieved at the 
> implementation
> level and without protocol support. That is not to say that 
> protocol work
> may not help and should not be done...but only to indicate 
> that "smooth
> handoff" work should be separate from the FMIP work. In fact, smooth
> handoffs could be viewed as optional extensions to the FMIP specs.

What do you mean by achieving smoothing at the implementation level?

I looked back at the low-latency spec and noticed an inconsistency in
that the simultaneous binding is a MAY in PRE-REG and a MUST in POST-REG.
I think the aim was to keep it as a MAY. So I would consider it as optional
already. What makes me unconfortable in putting all this in another spec
is that it would defeat one of the main purposes of this document:
reduce/eliminate service disruption due to handoff.
Or did you mean to state the problems in the FMIP drafts and have them
point to a new bicasting/buffering draft for optional implementation?
In both cases, having it in or outside the FMIP drafts, we must have
these "smoothing" options. What I don't understand is what the
difference is with what we have today? You don't need to implement
bicasting or buffering if you don't need it, so what you want is already
there.

Regards
/Karim

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 24 Jul 2001 17:25:17 +0200

George, 

	Just a couple of comments in addition to Karim's

> GT> This was discussed in (I think) much greater length in the FMIPv6 design
> team and enough doubts were raised to exclude bicasting from the FMIPv6 spec
> and encourage its proponents to publish the idea as a separate document,
> which they did...well done :). The main argument against bicasting was
> regarding its possible  effects on TCP. Bicasting would duplicate TCP ACKS
> (along with everything else) and as we know 3 dupacks result in TCP
> shrinking its window...dupacks occur naturally by TCP as a result of the
> network loosing or reordering packets and the chance of 3 dupacks in a row
> is not very high. We thought that bicasting may increase the chance of 3
> dupacks and thus impact TCP performance. 
> 
> Note that there has been work towards eliminating this well known problem
> and Karim can point the list to this work since I do not remember that draft
> name. Nevertheless, the FMIPv6 team decided that bicasting has experimental
> nature and the TCP fix was at the time a draft at v00...early days => not
> enough practical experiance or understanding of what a possiby wide spread
> use of bicasting do to TCP. For all the above we thought that bicasting
> 
	=> I don't think we can judge other people's work on TCP in this 
	WG. Because I know the author and have seen his experiments
	and know how long this work has been trialled for I can say that 
	your judgement is incorrect. Some 00 drats go straight to last
	call in many WGs. We all (the DT members for v6) got these 
	links and saw how long this work has gone for so I think 
	we can safely say that there is a solution.

> IMO smoothing (bicasting and/or buffering) should be separate specs from the
> FMIPv4/v6 not only because of the uncertainty regarding bicasting but also
> because (again IMO) smooth handoffs may be achieved at the implementation
> level and without protocol support. That is not to say that protocol work
> may not help and should not be done...but only to indicate that "smooth
	=> Respectfully disagree here (but I guess you knew that :)).
	The whole point of the draft is to provide minimal loss during 
	IP handovers. How can we claim that it's successful when 
	we have a section that says if we have ping pong then this 
	won't really work ?

	I just don't understand what having a different draft will achieve
	apart from more paper work last calls .....etc. 
	I prefer to discuss the technical merits which is why we agreed 
	to writing a draft in the first place.

	IMHO we should have one draft for v4 and one for v6 as was always
	planned. 

	Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 24 Jul 2001 11:37:36 -0400

-----Original Message-----
From: Karim El-Malki (ERA) [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 4:07 PM
To: [email-masked]'
Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

Hi George

GT> The nFA has no way of know at which point the transmission was severed
at the oldFA...i.e.: if the bicasted packets are buffered at the newFA
(which I assume they will so this is useful) the TCP issues remain!

GT> I mean that routers can buffer without the involvement of the MN i.e.:
without the need for a protocol based negotiation.

GT> I also stated that "smoothing" options are useful and are needed so no
disagreement there. I am only arguing that it is a separable piece of work. 
- multiple ways of smoothing are possible for the same FMIP mechanism
- there is a discussion to be made about buffering based methods vs
bicasting based methods. I think both have merit but recommendation of one
of the two would be nice interoperability/simplicity purposes
- smoothing work is not as mature are FMIP, has not been discussed at the
same detail which also points to the fact that are separable.

GT> Karim, my main argument in this thread is not against bicasting although
I have my own concerns which you are very well aware off. The question in
this thread is about separating "smooth" from "fast" specs and I think I am
not the only one who things this may be a good idea. It makes specs thinner
if nothing else and I, at least, believe that will make FMIP specs go
through the standards process faster...

GT> I think I have made my point others should comment too.

George

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Tue, 24 Jul 2001 18:03:12 +0200

> (which I assume they will so this is useful) the TCP issues remain!

Just a quick answer to this point. You're assuming that you will buffer
and that may not be needed. It's a MAY in low-latency. If you do buffer,
and have a fixed buffer/delay at nFA of the size of the duration of the
L2 handoff (when the MN is disconnected at L2 while moving between oFA
and nFA) then you shouldn't get duplicates. That's a possible solution
since the L2 handover period is normally known in wireless systems.

Rgds
/Karim

---

From: "Hongyi Li" <[email-masked]>
Date: Tue, 24 Jul 2001 12:27:12 -0400

Hi Karim,
  I think George was right in this point.
  For a single interface MN, if there is no synchronization between the
two FAs, the MN will experience either packet loss or packet duplication
depending on the direction of the handoff. 
  Here is an example, at time t, assume FA1 is transmitting packet with
seq no. x; FA2 is transmitting packet with seq no. x+2. If the MN handoff
from FA1 to FA2, packet x+1 will be lost. If the MN handoff from FA2 to FA1
the MN will receive duplicated packet x+1.
  Buffering without synchronization won't help here.

Regards

Hongyi 

> Sent: Tuesday, July 24, 2001 12:03 PM

---

From: James Kempf <[email-masked]>
Date: Tue, 24 Jul 2001 09:44:39 -0700 (PDT)

Hi Karim,

>The TCP issue is discussed with reference (EIFEL algorithm for TCP)

Agreed. The EIFEL algorithm should work.

>The TCP issues should not be involved.

The issue here isn't so much a second copy coming down the old L2
but rather that jitter on the oFA to nFA link or HA/RegReg Agent to oFA/nFA 
links could skew the packet delivery. This would result in a packet to nFA being
delayed so that the MN got a packet on the old L2, went through
handover, then got the same packet on the new L2 because it was delayed
by jitter. This is easily controllable by reducing the topological
distance over which bicasting occurs to reduce the probability of
jitter, and reducing the latency period during which L3 service is
not available to the MN.

>What do you mean by achieving smoothing at the implementation level?

I think he means L2, right George? The idea here is that if the
amount of time in which L3 is unavailable to the MN is low
enough the L2 protocol can handle lost packets by performing
retransmit. But you would still need to bicast because
otherwise the packet would not be at the new FA/AR.

>that the simultaneous binding is a MAY in PRE-REG and a MUST in POST-REG.

What do you mean by simultaneous binding? I think you mean bicasting.
POST-REG uses FA-FA bicasting with tunnels, not HA/RegReg Agent to FA bicasting, 
so simultaneous bindings are not needed.

>reduce/eliminate service disruption due to handoff.

I originally argued for putting a discussion of bicasting in the appendix,
but I agree that a specification of handover smoothing options and
a discussion of techniques is essential for a complete specification
of handover and guidance to implementors.

>point to a new bicasting/buffering draft for optional implementation?

I favor this approach. I would like to see a two handover smoothing
draft with protocol details of both approaches, one for IPv4 and one for IPv6, 
and one draft discussing handover smoothing and handover performance as a guide 
to implementors independent of implementation.

I also think the discussion of bicasting needs to distinguish between
the simultaneous bindings approach and the tunneling approach.
They have somewhat different properties.

>bicasting or buffering if you don't need it, so what you want is already

The issue is whether the two FMIP drafts say that one particular
smoothing option is a MUST, or just say that smoothing MAY
be necessary, and point to a separate draft where smoothing is
discussed.

I believe that there may be cases where smoothing may be unnecessary
(though I can't think of one off the top of my head), so it makes
sense to leave open the option, but I do believe it needs to
be specified.

		jak

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Tue, 24 Jul 2001 18:43:40 +0200

Comments inline.

-----Original Message-----
From: Hongyi Li [mailto:[email-masked]]
Sent: den 24 juli 2001 18:27
To: [email-masked]'
Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

Hi Karim, 
seq no. x; FA2 is transmitting packet with seq no. x+2.

>> Why is it transmitting x+2? It would be x-2 if FA2 (nFA) is buffering.
>> If so my suggestion was to set the buffer to the L2 handoff duration.

 If the MN handoff 

>> does it take zero time to perform a L2 handoff in this example?
>> If it does then I would expect FA2 to transmit x, while FA1 transmits x.
>> Then you don't have packet loss or duplication.

---

From: James Kempf <[email-masked]>
Date: Tue, 24 Jul 2001 10:12:08 -0700 (PDT)

Hi Karim/George,

>since the L2 handover period is normally known in wireless systems.

Yes, that's right. If the latency is low enough, you can simply
drop any packets that come through. For real time traffic this
will have no effect if the number of dropped packets is low
enough. For reliable protocols, such as TCP, it will cause
retransmit, which may or may not be a problem.

		jak

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 24 Jul 2001 14:41:50 -0400

James,

I agree with Mike regarding make before break but you also agreed with me in
earlier e-mail that smoothing can be done by an implementation buffering
without protocol/mobile's involvement...so FMIP does not need smoothing
specificiations to become useful even in break before make.

George
-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 6:51 PM
To: [email-masked]
Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

James Kempf writes:
 > The issue is whether the FMIP work is completely useless without 
 > smoothing, or whether smoothing is so intertwined with the FMIP
 > work that it is impossible to put it into a separate spec. I think
 > the fact that the FMIPv6 draft managed to successfully disentangle
 > them argues that the smoothing work can be separated out from
 > a design perspective. Whether or not FMIP is useless without
 > smoothing from an operational or implementation perspective
 > is something that can only be determined by experiment. 

   I'd say that it's not useless: if you have two interfaces,
   FMIP alone is probably sufficient since you can do a make
   before break while listening on both for some period of
   time. It might be pointed out that you could do that without
   the FMIP AR, but latencies back to the CN/HA may require a
   more localized solution to achieve a reasonable handoff.

		  Mike

---

From: "Hongyi Li" <[email-masked]>
Date: Tue, 24 Jul 2001 15:37:27 -0400

See my comments inline

-Hongyi

> Sent: Tuesday, July 24, 2001 12:44 PM

[hyli] this is just to show the different transmission speeds on
the two bicasting legs. The transmission speed depends on the traffic
conditions on different legs that include radio links as well. I don't
think we can over provisioning radio links in near future.
Buffering at the new FA still doesn't solve the problem. This is
because the transmission speed at old FA still matters. Let's assume
for example bicasting started with packet of seq no. x. If the old FA
is transmitting x-2 at handoff (due to poor radio link), packet x-1
will be lost; if the old AR is transmitting x+2 at handoff (good radio
link), the MN has packet duplication. 

> >> Then you don't have packet loss or duplication.

[hyli] Whether handoff takes zero time or dt is not important here. If a
system wants both FAs transmit x at the same time, good synchronization
mechanism is needed. 2G CDMA systems implement this synchronization
in soft handoff. However, this synchronization reduces the overall
throughput of the CDMA systems. You may find some HDR papers that explain
this problem.

---

From: James Kempf <[email-masked]>
Date: Tue, 24 Jul 2001 13:25:02 -0700 (PDT)

George,

I think we agree that specifications of smoothing and fast handoff do not need 
to be linked, if only for practical considerations. 

I think we agree that it is possible to do smoothing without mobile/protocol 
involvement (bicasting in BETH using tunnels is done that way, only
the routers are involved). 

I think we may disagree about the value of smoothing in actually implementing 
fast handoff. I have the impression you believe it may be possible to
deploy fast handoff completely without any smoothing, whereas I feel
that some smoothing will definitely be needed and that more experiments are 
necessary to quantify exactly what the technology should be. To that 
extent, I believe the fast handoff work is incomplete without discussion
of smoothing (which, I believe, is Karim's position), but I would rather see the 
WG move forward on what we agree on than get hung up on what we don't, given 
that it seems to be technically possible to separate out the specification of
smoothing from fast handoff.

		jak

>From: George Tsirtsis <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Date: Tue, 24 Jul 2001 14:41:50 -0400
>
>James,
>

---

From: "Hongyi Li" <[email-masked]>
Date: Tue, 24 Jul 2001 17:55:47 -0400

Hi James,
  
  My comments are inline.

Rgds

Hongyi

> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 4:39 PM
> Hongyi,
> I agree  with your analysis. Basically, what you are saying is that
> there can be jitter between the old link and the new that could
> result in duplicated packets going to the MN on the new link, 
> correct?

Yes. Jitter between old and new links could result in packet duplication
or packet loss in bicasting.

> 
> One way to mitigate this problem is for the FA to get better
> handover sequencing information from L2. For example, if nFA
> gets an L2 trigger when L2 handover begins, it can start buffering
> until the new L2 is fully stabilized. This reduces the window
> during which the nFA is buffering. Although it won't synchronize
> packet delivery, it will reduce the amount of buffered packets
> and therefore the potential for duplication. 
> 
> Another way to mitigate it is to make sure the wired network is 
> properly provisioned for the expected amount of traffic, to
> reduce the possibility of congestion and thus jitter. This will
> not, of course, solve the problem of the radio link on the 
> oFA slowing down. That can be mitigated with reducing cell
> sizes, etc. to avoid overloading, but, in general, if the
> radio propagation conditions become poor enough that retransmits
> are necessary, as you point out, oFA could lag behind the
> bicast stream. 
> 
> In general, I don't know any way to synchronize packet delivery
> between oFA and nFA. I believe CDMA does this by having a 
> very short window (something like 20 ms) during which soft handover
> occurs, and using GPS (in cdma2000) to synchronize soft handover
> between BTSs. This is not possible in IP, if for no other reason than
> the packet sizes can vary, and not all radio protocols have access
> to GPS synchronization. There are a variety of heurstics that
> could be used, however, and I think it makes sense to write
> them down.

I agree that it is very difficult to implement CDMA type of
synchronization mechanism in IP layer. Based on the perceived value and 
cost of implementing such a sync. mechanism, it would be better
to use heuristics to reduce the packet duplication or loss. The
heuristics can be used by network operators for improving their
network performance if bicasting is used.

> 
> 		jak
> 
> >From: "Hongyi Li" <[email-masked]>
> >Date: Tue, 24 Jul 2001 15:37:27 -0400
> >
> >See my comments inline
> >
> >-Hongyi
> >

---

From: "Hongyi Li" <[email-masked]>
Date: Tue, 24 Jul 2001 17:55:47 -0400

Hi James,
  
  My comments are inline.

Rgds

Hongyi

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 25 Jul 2001 12:31:52 +0200

>    more localized solution to achieve a reasonable handoff.
	=> Yes but if you have two interfaces then I'd argue that anticipation
	is not needed or not a realistic action to expect. This is due to the fact
	that most devices with two interfaces are typically connected to
	different access technologies. It seems unrealistic IMHO to expect 
	a WLAN network to anticipate your movement to a CDMA network
	and vice versa.

	All you would need in that case is a localised agent to minimise the BU latencies
	and the number of BUs sent. FMIP was not designed for the multi-interfaces
	case or if a system has a carefully designed make before break 
	handover. 

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 25 Jul 2001 12:38:56 +0200

James, 

> to be linked, if only for practical considerations. 
	=> I would like to understand your point here. What difference does it 
	make if we put the smoothing techniques in the same draft 
	(as the low latency draft does) or leave them out (as in the v6 draft) ?
	If we believe smoothing is essential as you said below then why keep it
	out of a draft which was designed specifically to reduce L3 losses and 
	delays due to the MIP handover ?

	If I'm implementing this function in a product, don't I have to do the smoothing
	anyway ?

	Therefore, I think for prctical reasons we should actually have them in the 
	same draft. Otherwise the only difference would be more drafts, more paper
	work and unncessary cycles consumed. 

	Hesham

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 25 Jul 2001 13:24:00 +0200

Regarding the CDMA thread, I think we're going away from the problem.
Synchronisation of basestations is important for soft handoff but I
cannot see the relation with the smoothing function we are talking about.
We just want to minimise the period the MN is disconnected at L3 following
a handoff (FMIP), but we do not aim to address recombination or anything
like that. Synchronising the basestations for soft handoff does not
mean that you won't get duplicate/delayed packets at L3. Of course, 
as pointed out by Arthur, its important to consider different L2
characteristics but in this case I think that getting into base station
synch issues is not relevant.

Rgds
/Karim

> From: Arthur Ross [mailto:[email-masked]]
> Sent: den 24 juli 2001 23:48
> At 13:39 -0700 07/24/2001, James Kempf wrote:
> >
> James et al:
> The issue here is the nature of the diversity that is available in 
> any given RAN technology. The simplest is unsynchronized multicasting 
> - packets are sent from more than one source, without any attempt at 
> synchronization other than that imposed by sequence numbering.
> 
> The various flavors of CDMA technology, on the other hand, employ a 
> very sophisticated symbol-by-symbol optimal ratio (in the downlink) 
> combining. This substantially improves error performance under 
> adverse propagation conditions. That combining is, in essence, a 
> vector sum of received symbol amplitude estimates from whatever 
> sources are available. The signal components add amplitude-wise, 
> while the noise components add power-wise (i.e. rss), hence the 
> improvement in overall SNR of the resultant. This technique relies on 
> the same sequence of symbols be radiated the various BTSs 
> participating in this "soft" handoff.
> 
> The CDMA return link diversity combining is done in a different way, 
> but also makes use of multiple symbol streams from the various BTS 
> receivers involved in the handoff.
> 
> As you say, this is done with the aid of GPS-derived precise timing. 
> Synchronization is not fundamentally necessary, but it is extremely 
> convenient in implementing the combining, and helps keep the latency 
> low. Other less precisely timed forms are possible in principle, but 
> have not, as far as I know, ever been proposed or implemented. To do 
> so would require substantially buffering and de-skewing of the symbol 
> streams. That buffering and deskewing would contribute objectionable 
> latency and variance of latency, both very objectionable in a speech 
> service.
> 
> The 20 ms of which you speak is the CDMA frame size. That size has 
> its origins in the size of the vocoder frames. The FEC is blocked in 
> those 20 ms frames - each frame can be decoded and CRC checked 
> independently. Again, not fundamental, but because of the dominance 
> of the speech service, it is probably here to stay, or at least will 
> be around for a long time.
> 
> Re "handoff smoothing" - It is, I think, desirable to recognize the 
> variety of diversity techniques that may be used in the radio link, 
> depending on the particular technology, and to provide the 
> tools/mechanisms the can accommodate that variety somehow. This is, 
> obviously, intimately intertwined with the QoS issues. What is ok for 
> a dumb datagram service may be manifestly awful for a speech service.
> 
> Just my 2 cents worth ...
> 
>     -- Regards, AHMR
>

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 25 Jul 2001 08:31:30 -0400

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 11:32 AM
To: [email-masked]'
Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

>    more localized solution to achieve a reasonable handoff.
	=> Yes but if you have two interfaces then I'd argue that
anticipation
	is not needed or not a realistic action to expect. This is due to
the fact
	that most devices with two interfaces are typically connected to
	different access technologies. It seems unrealistic IMHO to expect 
	a WLAN network to anticipate your movement to a CDMA network
	and vice versa.

	All you would need in that case is a localised agent to minimise the
BU latencies
	and the number of BUs sent. FMIP was not designed for the
multi-interfaces
	case or if a system has a carefully designed make before break 
	handover. 

GT> Hesham you make some assumptions here that I do not agree with..a single
radio technology can have make before break capabilities in which case a
node can be multihomed to two ARs for a short amount of time (via the same
interface/technology) and to the same domain. The multihomed time needs to
be minimized for radio/spectrum/resource efficiency reasons in which case
the FMIP specs become very useful indeed.

George

---

From: Phillip Neumiller <[email-masked]>
Date: Wed, 25 Jul 2001 08:25:39 -0400

James, 

Arthur's explanation is right on.  BTW, if you are interested in doing
handover smoothing over IP for CDMA/3G RANs see US patents:

6,226,283  Method and selector for performing selection in a communication
system  
6,141,559  Method and apparatus for performing selection and distribution in
a communication system  
6,072,790  Method and apparatus for performing distribution in a
communication system  

It is VERY possible to do macro-scopic diversity combining/selection OVER
IP.  In fact SCTP offers a nice way to do this.  My two cents...

Phil Neumiller
MeshNetworks, Inc.

> Sent: Tuesday, July 24, 2001 5:48 PM

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 25 Jul 2001 08:25:56 -0400

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 11:39 AM
To: [email-masked]'
Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

James, 

> to be linked, if only for practical considerations. 
	=> I would like to understand your point here. What difference does
it 
	make if we put the smoothing techniques in the same draft 
	(as the low latency draft does) or leave them out (as in the v6
draft) ?
	If we believe smoothing is essential as you said below then why keep
it
	out of a draft which was designed specifically to reduce L3 losses
and 
	delays due to the MIP handover ?

GT> The difference is that we have relative agreement on the FMIP specs NOW!
We do not have the same agreement on smoothing...putting them together will
delay both which is not what we want...I think...

	If I'm implementing this function in a product, don't I have to do
the smoothing
	anyway ?

GT> You may do...but as I said there are ways to do smoothing without any
"protocol work" i.e.: a router can buffer or even bicast without involving
any other element in the network in which case there is no need to have a
protocol specification for it and your implementation can still work fine. 

George

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 25 Jul 2001 14:40:56 +0200

> interface/technology) and to the same domain. 
> 
	=> Understood. That's what I meant in the last line above. 

> The multihomed time needs to
	=> Yes but could it not be long enough to send one BU ?

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 25 Jul 2001 14:47:26 +0200

> delay both which is not what we want...I think...
	=> Ok so the difference is on the technical merits of the solution. 
	Hence putting it in another draft will not solve this difference. 
	So why don't we discuss these differences on the technical side
	first and agree to have the solution or not have it altogether (ie in any draft) ?
	Wouldn't that be better for the group, instead of writing another
	set of drafts and dragging this for even longer periods.

> "protocol work" i.e.: a router can buffer or even bicast without involving
	=> There are two cases that are common in both the v4 and v6 
	drafts. In one case the MN sends a BU/registration and in another 
	it doesn't.
	What you say above is applicable to the latter but not the former. 
	A MN must be able to request bicasting otherwise if it moves 
	back to the old AR (ping pong) it will need to send a new BU
	since it will have no knowledge that bicasting was happening
	or for how long. So this case would require the protocol 
	work described in the bicasting draft. 

	Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 25 Jul 2001 08:52:05 -0400

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 1:41 PM
To: [email-masked]'
Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

GT> That is a call that we can not make here but you can imagine that
weather is long enough to send a BU may depend on many factors like RTT
times and topological distance between ARs etc...No matter, I think the
point was that FMIP can be useful in make before break.
George

---

From: James Kempf <[email-masked]>
Date: Wed, 25 Jul 2001 08:55:02 -0700 (PDT)

Hesham,

>	set of drafts and dragging this for even longer periods.

The problem is that the technical disagreement is so severe it will
probably take a couple of implementations and some data collection
to work them out. At least, that is my perception. And that takes
time.

		jak

---

From: James Kempf <[email-masked]>
Date: Wed, 25 Jul 2001 09:03:41 -0700 (PDT)

Behcet,

I don't think anybody has proposed integrating LMM, FMIP and smoothing,
and, in fact, I think that would probably draw out the standardization
even longer.

W.r.t. LMM, we should probably start a separate thread about what to
do, which I will let up to you if you like.

		jak

>Date: Wed, 25 Jul 2001 10:56:40 -0500
>From: Behcet Sarikaya <[email-masked]>
>Subject: Re: [mobile-ip] Handover Smoothing - What to Do?
>
>Fast handovers are good, smooth and fast handovers are even better.
>I favor coming up preferrably a single draft which achieves this integrated 
into the
>LMM, and it seems that the leading draft for LMM is HMIP.
>
>This put into the fast track standardization should resolve Raj's concerns.
>Any thoughts on this?
>
>Regards,
>
>James Kempf wrote:
>
>> Hi Hesham,
>>
it
draft) ?
it
and
>> Like I said, practical considerations. The difference may be a year
>> delay in whether the base FMIP gets through the IESG to proposed standard.
>> I think there is wide agreement (dare I say rough concensus? :-) on FMIP,
>> but there appears to be no concensus on smoothing.
>>
the
>> smoothing
>> >       anyway ?
>> >
>>
>> Agree 100%. But we've got to have a better understanding of
>> the issues before we can standardize.
>>
>> >       Therefore, I think for prctical reasons we should actually have them 
in
>> the
>> Well, I understand where you are coming from, as I would like a complete
>> handover solution to be done soon too. But realistically, it takes as
>> long as it takes. If we can peel off the FMIP work and get IESG to
>> take a look at that, we can reduce the amount of time later when
>> we do reach concensus on smoothing.
>>
>> I'd like to hear from the WG chairs and ADs on this, I guess, since
>> it seems to me basically a procedural issue. Raj has already come
>> out for keeping smoothing separate for now, what do the rest of
>> you think?
>>
>>                 jak
>
>--
>Behcet
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 25 Jul 2001 18:18:17 +0200

Hi James, 

	I'll respond to both mails in one. 

> delay in whether the base FMIP gets through the IESG to proposed standard.
	=> I don't understand the reasoning here. You say in another mail 
	that the technical differences are severe. So far I haven't heard one 
	technical objection yet. All the objections are on whether we should have 
	it in the same draft or not. Since I know you do agree with the concepts 
	for smoothing, it would be good if people highlight exactly what's 
	missing (_technically_) in the proposal. This shouldn't take long.

	As for the technical concerns raised in the v6 DT (I don't know
	if you know about these) they are all addressed in the draft.

	As to whether we have agreement on FMIP, we do agree so far 
	on the v4 draft (no one objected to the bicasting or buffering there)
	but certainly I can't agree that the v6 draft is ready when there 
	is a major gap that would cause packet losses. The gap is addressed
	in the v4 draft and no one objected to that. 

> the issues before we can standardize.
	=> I can only speak of our propsal, this is almost 18 months old 
	now. This is quite unusual for a draft. So I think now is the right time 
	to voice concerns. 

> we do reach concensus on smoothing.
	=> MIPv6 is a good analogy. It can't go ahead because security
	is an integral part of the solution. The initial goal o Fast Handoffs 
	was to minimise latencies and packet loss due to MIP handovers. 
	If we introduce anticipation without a supporting mechanism 
	then we haven't actually met the initial target.

	This discussion can carry on for a long time, but as I said 
	above, without people voicing technical objections we're
	really wasting the WG's valuable time. 

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 25 Jul 2001 18:21:53 +0200

Hi James, 

> and, in fact, I think that would probably draw out the standardization
	=> No need to do addition standards work for that. we proposed it,
	Please check :
	http://www.globecom.net/ietf/draft/draft-elmalki-soliman-hmipv4v6-00.html
	which was presented in Adelaide last year and Appendix A of the new
	HMIPv6. They show how FMIP and HMIPv6 can be combined

> do, which I will let up to you if you like.
	=> Agreed.

	Hesham

---

From: James Kempf <[email-masked]>
Date: Wed, 25 Jul 2001 09:29:34 -0700 (PDT)

Hi Hesham,

>	if you know about these) they are all addressed in the draft.

Yes, that's what I meant. My impression from George's email is
that he is still not comfortable with the work in the draft. Hongli
also brought up the issue of jitter. I'm working on a note
concerning that at the moment, which I hope to post later today.

>	in the v4 draft and no one objected to that. 

I believe the intent is not to completely exclude mention of
smoothing, but rather to make a reference to it in the FMIP drafts.
Of course, if we do this, then we have effectively linked them, because
the FMIP drafts can't go to RFC without the smoothing drafts also
going to RFC.

>	really wasting the WG's valuable time. 

I certainly agree there. 

		jak

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 25 Jul 2001 13:20:33 -0400

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 5:30 PM
To: [email-masked]
Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

Hi Hesham,

I certainly agree there. 

GT> My very first e-mail on this thread included a *technical* concern about
this...which boils down (again!) to the undisputed fact that bicasting may
affect TCP in the ways I stated before and in the circumstance that were
discussed in this thread. The argument has not been disputed; Instead
Hesham/Karim has pointed to the EIFEL work which I bet is good and it
actually confirms that there IS a problem with bicasting (otherwise why is
there a draft about fixing the problem??). My objection to this is that even
if Eifel becomes a standard RFC today it would not help! the question is how
long it would take to go into all the Internet connected Hosts...albeit long
time? Any word from Microsoft implementing it yet? So, IMO a spec that
suggest a mechanism that at the moment has unknown potential effects to the
Internet at large I think is not responsible behavior by the IETF, even if
it is only a MAY. Putting bicasting in a different draft would allow it to
become Information or Experimental RFC until EIFEL becomes available and we
get some implementation experience.

I think it is unfair to say that the argument is not technical...we have
actually discussed this before in the DT and every time it kind of annoys me
when you guys say that. It seams that you think that my technical objection
is not important and I respect your opinion but that does not mean that
there is no *technical* argument.

I hope the WG chairs make a decision on this...I think the arguments are
reasonably clear and there is no point discussing this further unless
*other* people want to voice opinions.

Regards
George

---

From: James Kempf <[email-masked]>
Date: Wed, 25 Jul 2001 10:34:04 -0700 (PDT)

George,

I think there are ways to reduce or eliminate the problems with
duplicate packets. I just sent out an analysis on this.

I understand your concerns about EIFFEL.

		jak

>Date: Wed, 25 Jul 2001 13:20:33 -0400
>
>

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 25 Jul 2001 20:33:28 +0200

George,

> discussed in this thread.

It's not undisputed actually. In one of my previous emails I
pointed out that the circumstances considered in low latency do
not involve multiple packet delivery. The MN does not receive
from multiple FAs and we use a smoothing mechanism in a way such
that it does not get multiple copies of packets. So I'd say that
bicasting should not be linked to TCP effects, unless your system
is implemented in a way that the MN does receive multiple copies
of packets. I think I gave an example where, if you bicast and
buffer at nFA for a period equal to the L2 handover time, then
you won't get duplicates.

> The argument has not been disputed; Instead
> there a draft about fixing the problem??).

No! EIFEL was not done to eliminate bicasting.
This has nothing to do with bicasting.
In general there is no guarantee that an IP network will give you
in-order packet delivery or a single copy of packets delivered to
you. That's independent of bicasting.
So if you want to run low latency with bicasting and have a MN
which can be simultaneously communicate with multiple FAs, then
EIFEL helps solve the TCP problem.

>My objection to 
> this is that even

Well, you seem to be convinced that bicasting means
that the MN receives multiple copies of packets. I tried my
best in explaining why that won't happen...
Haven't seen a good explanation as to why multiple packet delivery
to the MN MUST happen with bicasting, that's the fundamental point.

Rgds
/Karim

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 25 Jul 2001 14:51:49 -0400

I think I have already replied to these questions...we do not seam to be
connecting here...never mind we have both made our points...the group can
decide. We can have a beer over it in London....or maybe many I do not think
just one will be of any help :-)

George

-----Original Message-----
From: Karim El-Malki (ERA) [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 7:33 PM
To: [email-masked]'
Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

George,

Rgds
/Karim

---

From: Phil Roberts <[email-masked]>
Date: Wed, 25 Jul 2001 14:54:08 -0400

> you won't get duplicates.

Can you tell me which email this is - I'd like to read it?  You'll
need it in the draft at a minimum.

> to the MN MUST happen with bicasting, that's the fundamental point.

Not must necessarily, but is sometimes possible.

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 25 Jul 2001 21:36:26 +0200

> need it in the draft at a minimum.

My mail to George on the 24th July about bicasting and buffering at nFA.
I think it's similar to the jitter buffer issue that Phil pointed out
in reply to a mail from James. The bicasting draft (as the low latency
draft) allows the nFA to drop or buffer packets for a MN which is not
yet connected. So the buffering or dropping at nFA is specified, but I
can add more of the reasoning.

> Not must necessarily, but is sometimes possible.

Agreed. So we aim to avoid duplication of packets. If we can achieve this
as above then nothing more is needed. If that is not possible in other
cases (e.g. multi-interfaced MNs are using FMIP+bicasting) then TCP
solutions such as EIFEL should be applied. Both are addressed in the
bicasting draft.

---

From: Phil Roberts <[email-masked]>
Date: Wed, 25 Jul 2001 19:31:06 -0400

> So that's why we went for this solution and allowed bicasting.

Thanks for the pointer to this.

I'm glad it is specified as a MAY.  I'm a little puzzled about why you
think what you've described solves your problem and doesn't introduce
the possibility of multiple copies of a packet being delivered.  How would
you implement the two FAs?

They are both receiving packets without any knowledge of what the other
has received, or has forwarded to the MN.  Might you not have a situation
like this?

At a single point in time the MN is no longer reachable from the oFA and is
not yet reachable on the nFA.  At that point in time a packet arrives at
both
oFA and nFA and they discard the packet.  The MN attaches to the nFA but the
packet is gone.  (That's in case A you describe).

Or like this?

At a single point in time a packet arrives at the oFA and is sent to the MN
and
at the same time arrives at the nFA and gets buffered.  The MN disconnects
and then reconnects at the nFA and gets a second copy of the packet.
(That's
in case B you describe).

Or like this?
The same packet arrives at oFA and is transmitted to the MN which then moves
to the
nFA and gets the same packet which was delayed on its way to the nFA.

Or like this?
The MN disconnects from the oFA the packet arrives and is dropped, then the
MN comes
back to the oFA because of radio conditions and the packet has been lost.

It seems like there is some coordination needed between the oFA and the nFA
to
overcome these problems, perhaps a temporary tunnel?  But in that case
bicasting from
an HA or a hierarchical FA wouldn't be adding much to it, would it.  At any
rate
one would think that issues like this need some exploration and explanation
somewhere.

Phil

---

From: James Kempf <[email-masked]>
Date: Wed, 25 Jul 2001 13:45:47 -0700 (PDT)

Pat,

I agree.

		jak
>Date: Wed, 25 Jul 2001 12:21:14 -0700
>From: Pat Calhoun <[email-masked]>
>Content-Disposition: inline
>User-Agent: Mutt/1.2.5i
>
>I unfortunately agree with most folks that disagree with each other. On
>one hand, the low latency draft without smoothing techniques is incomplete,
>but on the other hand, additional (and perhaps even better) techniques may
>be developed over time.
>
>So, one alternative is to add text to the fast drafts that without such a
>technique, the draft is incomplete. Then the WG could develop a series of
>smoothing techniques (perhaps each in separate drafts, but well identified). 
>
>So, the fast draft does point to external work, and it does claim that by
>itself it really is incomplete, but on the other hand, it isn't tied to
>a specific mechanism, and allows for future extensibility.
>
>My 2 cents,
>
>PatC
>On Wed, Jul 25, 2001 at 02:03:44PM -0400, Phil Roberts wrote:
>> I wouldn't call it a procedural issue but a need to make a decision.  I
>> (personally)
>> would like to make a consensus call on both FMIPv4 and FMIPv6 right after
>> London and I don't want to send up drafts one with and one without an option
>> for smoothing.  So our consensus calls will probably be something like 1) do
>> we want smoothing in a separate draft and if so, 2) is FMIPv6 ready for last
>> call and is FMIPv4 ready for last call after we remove the smoothing bits;
>> and
>> if not 3) is FMIPv4 read for last call and FMIPv6 ready for last call after
>> we add the smoothing bits.
>>   
>> Right now it seems that George at least is uncomfortable with making
>> smoothing an essential part
>> of the FMIP draft.  Hesham at least is uncomfortable with progressing the
>> FMIP draft without smoothing.  Hesham's position excludes the middle ground
>> of putting smoothing into a separate draft.  As an aside it seems clear that
>> smoothing is an optional feature in the FMIPv4 draft but I'm not sure
>> whether
>> the proposal is to make it optional when incorporated in FMIPv6.
>> 
>> 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.
>> 
>> 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.
>> 
>> Does this seem to summarize everyone's position accurately?  Does this
>> answer your question
>> enough, Jim?
>> 
>> Of course, others contributing to the conversation COULD help,
>> Phil
>>

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 26 Jul 2001 09:41:45 -0500

Hello Rajeev:
Please see my inline reply.
regards,
ajoy 

I would like to mention the issue surrounding header compression and bicasting.
I posted a separate e-mail on this topic BTW. The problem is what type of a
packet does the old-AR bicast ? If it is uncompressed, then the new-AR needs
compression context to forward the compressed packet to the MN. Unfortunately,
this means support for Many-to-One mode of header compression (the two ARs to
the MN) which to my knowledge has not been defined. Thanks [rohc]! If the
old-AR bicasts a compressed packet to the new-AR, how does the new-AR forward
that packet ?

ajoy: I do not understand why new AR can not forward compressed packet to MN. 
If new AR can maintain a mapping of tunnel id versus MN id, it can forward the compressed
packet to MN. If you use GRE tunnel between newAR and oldAR, you can use key field of GRE to identify the flow. Access router does not always need to look at destination IP address to forward the packet. Please look at RFC 2890 for GRE info.  

For example, when some node acts as L2TP LAC, the access router does not
look at the destination IP address of IP header to forward the packet to the dialup client. 

In the uplink, only the old-AR would have the up-to-date context. This
introduces synchronization issues even when the new-AR may concurrently possess
the header compression state.

So, it is perhaps premature to state that there is consensus. I think bicasting
must not be coupled to FMIPv6. It could ofcourse be a separate draft.

My two cents..

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 6:18 PM
To: [email-masked]
Subject: Re: [mobile-ip] Handover Smoothing - What to Do?

Hello Phil,

Phil Roberts wrote:
[snip]

> the possibility of lost packets and the results should be documented.

I would like to mention the issue surrounding header compression and bicasting.
I posted a separate e-mail on this topic BTW. The problem is what type of a
packet does the old-AR bicast ? If it is uncompressed, then the new-AR needs
compression context to forward the compressed packet to the MN. Unfortunately,
this means support for Many-to-One mode of header compression (the two ARs to
the MN) which to my knowledge has not been defined. Thanks [rohc]! If the
old-AR bicasts a compressed packet to the new-AR, how does the new-AR forward
that packet ?
In the uplink, only the old-AR would have the up-to-date context. This
introduces synchronization issues even when the new-AR may concurrently possess
the header compression state.

So, it is perhaps premature to state that there is consensus. I think bicasting
must not be coupled to FMIPv6. It could ofcourse be a separate draft.

My two cents..

-Rajeev

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Thu, 26 Jul 2001 16:44:21 +0200

> has received, or has forwarded to the MN.  Might you not have 

I agree that there should not be the need for nFA to know what
oFA has transmitted. What I'm saying is that if you bicast and
(if needed) have an appropriate (jitter) buffer size at nFA then
it should be possible to avoid duplicates. More below.

> packet is gone.  (That's in case A you describe).

I would think that this is an effect of L2 (i.e. L2 handoff time)
and we are mostly aiming to minimise/eliminate effects due to L3.
Also what I was pointing to is that a buffer is probably needed
if the handoff time from oFA to nFA is not negligible (your next
case and this case). That's why packet dropping is a MAY. So this
case wouldn't happen, unless of course it's not TCP and you don't
care about dropping some packets. In fact low latency handoffs are
probably most useful for real-time services (e.g. Voice on UDP)
in which case, if there's an period of L2 disconnection during
handoff, the packets should be dropped.

> and then reconnects at the nFA and gets a second copy of the packet.

The buffer size should be set such that you don't get duplicates.
By the time MN connects to nFA, the second copy of the packet
should be dropped out of the FIFO queue/buffer and the next one
should be ready for sending to MN. Of course this calculation
depends on the l2 handoff characteristics and possibly the wired
connectivity between the bicasting point and oFA/nFA.

> nFA and gets the same packet which was delayed on its way to the nFA.

That would again need to be handled by a jitter-smoothing buffer at nFA.

> back to the oFA because of radio conditions and the packet 

We could devise some temporary oFA buffer for this, but the L2
handoff failure is pretty serious so I think that it is
too much to expect smooth handoffs in this case. If we can
maintain L3 connectivity then I think that should be good enough.

> an HA or a hierarchical FA wouldn't be adding much to it, 
> would it.

Well, I think that having a local central HA would help.
Say that oFA and nFA are at an equal distance from the GFA
which is the aggregation router between the two. That could
alleviate jitter on the fixed network, as has been already
mentioned by James. Also, if oFA and nFA happen to be connected
to each other through the GFA router, then bicasting at the
GFA would be more efficient.

>At any

OK. Up to now there has been a lot of emphasis on TCP. Although I
agree that it would be useful to give more detail of how bicasting
+ buffering works with TCP, we are also not considering the fact that
a major driver for having faster handoffs at L3 was to support
real-time services (over UDP). I would think that the issues above are
not applicable to this case? If this is so then we should not apply
these issues to bicasting/buffering in general and make that clear too.

Rgds
/Karim

---

From: Phil Roberts <[email-masked]>
Date: Thu, 26 Jul 2001 11:09:51 -0400

Well, I don't buy a lot of your response below, but notwithstanding that,
some documentation of how these cases are handled needs to be made so
it's available for scrutiny.  It seems that it should discuss the sizes
of these buffers and the criteria for determining when to forward and when
to drop packets, and what bicasting doesn't do for you.  Perhaps some
guidance
on how the agents involved in the implementation distinguish between and
handle different types of traffic should be included, because although the
proposals
are intended to help in the case of realtime traffic, the implementation
agents
unless otherwise informed are subject to the effects of implementing
the protocols for all traffic?

> Sent: Thursday, July 26, 2001 10:44 AM

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 26 Jul 2001 11:03:20 -0400

Absolutely Mike. 

If the ROHC packets are sent over the air to the MN, he decompressor 
states for the two streams will diverge rapidly (I'm imagining that 
they diverge exponentially, which would make the state relationship
chaotic, but that's for another mailing list). 

The reason they will diverge is due to the inevitable gross differences 
in behaviour of the channel between old AR and MN compared to the 
behaviour of the channel between new AR and MN. The ROHC compression 
algorithms are designed to adapt to varying channel conditions, and 
thus will adapt differently to the two different channels (which is 
why the "many-to-one" mode Rajeev mentioned appears to me to be
a very complex problem to solve).

Gary

> Sent: July 25, 2001 19:32
>  > >On the other hand,
>  > >if the new-AR has to possess the context 
> *simultaneously*, this adds a new
>  > >dimension to header compression: Many-to-One header compression! 
>  > 
>  > I don't follow. If the old AR gets the trigger for context transfer
>  > soon enough, it can send the header compression state to the new
>  > AR. New AR installs it, compresses incoming bicast packet headers.
> 
>    The problem is that you have one ROHC context with two
>    packet sources, AR1 and AR2. Sounds like the ROHC context
>    needs to be forked (cloned) on MN too, and the MN needs to pay 
>    attention to the i/f it came in on for real (which already
>    does, I assume).
> 
> 	   Mike
>

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 26 Jul 2001 14:44:00 -0400

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 6:11 PM
To: [email-masked]
Subject: Re: [mobile-ip] Handover Smoothing - What to Do?

Rajeev's email seems to be in line with my position. The only remark I have
is to
not to disregard the LMM due to whatever reasons.

If there is a bar meeting planned on this in London, count me in.

GT> I think the whole IETF IS a bar meeting :-)
George

---

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

I believe both the low latency MIPv4 and FMIPv6 protocols will work regardless of 
smoothing or lack thereof. They may not work optimally, but they will work.
As such, I believe we could separate out smoothing along the lines of Pat's
comments a few days ago.

However, I do believe that we need to agree on a consistent editorial position.
The worst course would be to have one set of specs that have smoothing
in them and one without, which is currently where we are at. This would be confusing 
to implementors, and it also looks unprofessional and just plain tacky.
		jak

>Hello Rajeev,
>
>This matches my view which, along with other members of the
>design team, I maintained during all of the discussions.
>We agreed during the meetings that smoothing techniques
>for handovers would be considered separately, and thus that
>both buffering techniques and bicasting techniques would not
>be specified within the fast handover draft.
>
>Regards,
>Charlie P.
>
>
>
>
>Rajeev Koodli wrote:
>> 
>> George,
>> 
>> George Tsirtsis wrote:
>> 
>> > Sent: Thursday, July 26, 2001 6:28 PM
>> > ...
>> > Reiterating my point, this must not be part of FMIPv6. Time permitting,
>> > I will work on a separate draft for smoothing and HC and outline these
>> > issues in detail.
>> >
>> > GT> Rajeev, just to make sure I understand, do you think that bicasting
>> > should be part of FMIPv4 instead or you just do not care about it so match?
>> > Are the concerns you have IPv6 specific in any way?
>> >
>> 
>> Rajeev: My personal opinion (without having participated in the design team
>> discussion!) is that any fast handover protocol must be able to work without
>> having to rely on a particular smoothing technique. This is especially
>> important when practical experience is absent. We are working on FMIPv6
>> implementation and we hope to be able to shed some light (on smoothing) in
>due
>> course of time.
>> Hope this helps.
>> 
>> Regards,
>> 
>> -Rajeev
>> 
>> >
>> > George

---

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

>Sounds unnecessary, especially for implementing FMIPv6. Bicasting must
>not be part of FMIPv6.
>

Nor should buffering! And likewise for low latency MIPv4.

		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 26 Jul 2001 18:17:33 -0700 (PDT)

Hi Rajeev,

>First, what is this soon enough ?

Soon enough is before the old AR starts sending packets, so new AR
can compress when the first packet gets there.

> Second, you need special route entry to make
>sure that a packet addressed to old-IP address of the MN is properly forwarded.

What special route? It's just a tunnel. See RFC 2473 about how to do IPv6 
tunnels. Tunnels are a standard IPv6 router function, no?

>Third, the some fields do not necessarily remain constant due to processing at
>new-AR. What happens to the Hop Limit and perhaps the Traffic Class field ? If
>they change, how does the MN's compression engine know about this ?
>

Old AR puts a tunnel header on, new AR strips it off. The carmel
core of the original packet is unchanged. Thus, new  AR gets to
compress just as old AR would have.

>If there is a context at both the ARs, the uplink context is current only on 
the
>old-AR to which the MN is connected. The MN does not transmit packets to both 
the
>ARs (uplink bicasting) correct ?

The new AR is also getting the packets, so it can also compress, even
though MN isn't there to take them. Or are you thinking that 
compression will require some over the air traffic on the old
L2 that will cause the context to change on the old AR? My recollection
is that once the context is established, it doesn't change unless
the header changes (i.e. it is not dependent on the channel, just
on the contents). Need to check the ROHC algorithms, though.

>Hope this helps.
>
>Anyway, my point is there are (important, hairy) issues to consider when 
combining
>bicasting with compression. I don't want unwanted complexity in implementing
>header compression due to bicasting (even if you can specify how to do it)! If 
you
>really want bicasting, propose it as a separate draft.
>

What I want is *smoothing* (i.e. bicasting *and* buffering) to be in
a separate draft. For both IPv6 and IPv4...

		jak

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Fri, 27 Jul 2001 13:04:41 +0200

> Well, I don't buy a lot of your response below, but 

Since you're expressing an opinion against this it would
be useful to know the reasons rather than just saying you
don't buy my response.

> the protocols for all traffic?

I'm not sure that specifying buffer sizes is something we should do,
we can just give some simple explanation of what factors the
calculation should be based on. The choice of buffering/bicasting
and that calculation should be left up to implementors who know more
about the system they're building on. We'll never solve all the problems,
but at least we can identify the gaps and supply the tools. Regarding
identification of traffic type, this was brought up a while back. It
would need some filtering at AR/FA. There is also a proposal to move
only certain flows:
http://search.ietf.org/internet-drafts/draft-soliman-mobileip-flow-move-00.txt
A BU could eventually identify which flows to be bicast and which
not. That could be an alternative to filtering traffic at the ARs/FAs.

However it will be up to the implementor in the end to balance the
complexity, performance of real-time, performance of non-real time
against their applications. If someone's top priority is to get max
performance for VoIP and other traffic has lower importance then that
decision will influence the implementation. If we supply some tools
for this (and for the opposite case) it certainly helps. I had
interpreted the MAYs in low latency to be these tools, and if there
are others all the better.

/Karim

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 27 Jul 2001 08:56:44 -0400

Hesham,

I think people say: "leave smoothing out of FMIP specs so we can take FMIP
specs forward and have more time to debate smoothing which does not enjoy
the same consensus FMIP does...

Regards
George

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Friday, July 27, 2001 12:11 PM
To: [email-masked]'
Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

James, Rajeev and all, 

IMHO there is absolutely no gain or benefit in discussing whether
smoothing should be in draft X or Y. The question was do we want 
the bicasting technique or not ? putting it in the right draft is 
something secodary that will not add value to this discussion. 

It seems like some people are saying we don't care as long as you 
keep it out of this draft !! what's the point of this argument ? 
Putting it as MAY (as it is in the MIPv4 draft) will have the same 
effect. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 27 Jul 2001 15:03:54 +0200

Hi George, 

> the same consensus FMIP does...
	=> Understood. My point is that this is a waste of time to discuss. 
	We should discuss what smoothing is needed, namely the proposed 
	bicasting in the draft and mentioned in BETH and get consencus: yes or no.
	If no, then it's no for any draft in MIP. If yes then there is consencus and
	therefore it shouldn't matter where. 

	Discussing where it should go when we clearly don't have consencus 
	on whether it's good or bad is a complete and utter waste of time IMHO. 

	Cheers,
	Hesham

---

From: Phil Roberts <[email-masked]>
Date: Fri, 27 Jul 2001 10:00:35 -0400

Well, actually, the v4 draft seems to say it's MAY for PREREG and MUST
for POSTREG.

> Sent: Friday, July 27, 2001 7:11 AM

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 27 Jul 2001 16:07:12 +0200

> Well, actually, the v4 draft seems to say it's MAY for PREREG and MUST
	=> Yes I think that was a slip. We should fix that
	(MAY for both). Karim you mentioned this last 
	week was it MAY for both ? I think the rest of 
	the authors agreed with that. 

	Hesham

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 27 Jul 2001 10:53:33 -0400

James:

  Just a point of clarification: the scenario you are describing
only applies to digitized voice with voice activity detection. 
The delay you add with jitter buffering still translates to 
end-to-end delay of the voice. Probably the only big advantage
you get is that you don't have to worry about de-jittering the
silence periods, and thus have less packets to buffer.

Gary

> Sent: July 26, 2001 21:32
> Hi again Rajeev,
> >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.
> >
> 
> It doesn't have anything to do with the network dynamics. If 
> I buffer during
> time T(0), then it takes me T(1) to download, so I must buffer during
> that period. I download the T(1) buffer during time T(2), during
> which time I have to download, etc. It's a simple geometric series.
> Look in Appendix B of draft-kempf-beth-ipv6-01.txt for the math.
> 
> On second thought, maybe I ought to just post a summary of 
> the analysis,
> since we seem to be talking around it.
> 
> 		jak
> 
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 27 Jul 2001 18:30:22 +0200

> > 	- We've introduced a new concept in the v6 draft (and 
> > 	the v4 one) and that is anticipation. This can have 
> > 	negative impacts if not treated carefully. Right now it 
> > 	isn't treated carefully in the v6 draft so I don't believe
> > 	the draft can go ahead with a gap in it because some 
> > 	of us are not sure about the fix. I say we wait until we're
> > 	sure. Anyway the FMIPv6 draft will not become an RFC before
> > 	MIPv6 I hope. So what are we so rushed for ?
> 
> That fine, but we cannot postpone the low latency v4 draft just because 
> the v6 one isn't ready to go.
> 
	=> I didn't suggest that. I'd like it to go to last call after London
	and I thought we (the authors) agreed on that. It's fine as it is 
	and we got no comments suggesting anything was missing. 
	I guess that's why we have this question on the agenda

	Hesham

---

From: Phil Roberts <[email-masked]>
Date: Fri, 27 Jul 2001 10:02:59 -0400

> Sent: Friday, July 27, 2001 7:05 AM

This is a fair request.  Will try to send out something detailed
later today.

---

From: Phil Roberts <[email-masked]>
Date: Mon, 30 Jul 2001 09:28:01 -0400

Hesham,

We've made a distinction in our discussions all along between fast and
smooth.  To say that the fast handover proposals "don't work" because
they are not smooth seems to be confusing these two issues.

I outlined some cases in an earlier mail in which bicasting could be used
but the handover not be smooth.  Bicasting makes it possible that both (or
all)
FAs (or ARs) receive a copy of the packet with the hope they can do
something
meaningful with them to make the handover smooth.  This is commendable, but
perhaps something better could be attained.  So it seems worthwhile to
separate
fast and smooth in our work.

I think we've got the fast part fairly well handled.

Phil

> Sent: Monday, July 30, 2001 7:35 AM
> > >         There are so many mails I hope no one else made the same
> > >         comments that I'm about to make.
> > >
> > > > 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.
> > > >
> > >         => You're making a statement that is not backed 
> by a reason. See more below.
> > >
> > >
> > 
> > On the contrary, I was reasoning that when FMIP can 
> progress without having to rely on
> > any particular smoothing technique.
> > 
> 	=> See an answer below.
> 
> 
> > > > FMIPv6 must be able to work independently
> > > > of bicasting.
> > > >
> > >         => Why ?
> > >
> > >
> > 
> > Why not ? FMIP can work without any dependency.
> > 
> 	=> It _does_not. The draft clearly states that there 
> are cases (like ping pong)
> 	where the current solution does not work. We've said this many 
> 	times and it's in the FMIPv6 draft.
> 
> >  Besides, the smoothing techniques by
> > themselves are not well-understood to be part of a 
> standard. I mentioned this (in the
> > same thread somewhere) didn't I ?
> > 
> 	=> This is handwaving, I'd prefer if you point out 
> specific issues. 
> 	I don't think HC and CT has any role here. Bicasting 
> adds nothing 
> 	to the complexity of the HC CT (which is already very complex
> 	and of unproven value as it is). We can't build a 
> solution taking into 
> 	consideration a solution that does not exist or even agreed on.
> 
> > >
> > > > 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.
> > > >
> > >         => Well other proposals are also welcome. But I'm 
> sure you can appreciate
> > >         that new ideas come up all the time, that doesn't 
> mean we don't make
> > >         any decisions. We have to decide on what we have 
> now. Unless you've
> > >         done some experiments on bicasting and saw that 
> it's bad for some
> > >         reason.
> > >
> > 
> > We are now talking about handling smoothing techniques on their own.
> > As I mentioned above, this topic by itself needs a lot of 
> discussion before we can make
> > decisions. I am not convinced that we can draw definitive 
> conclusions on smoothing
> > techniques to progress them on a standardization path.
> > 
> 	=> Frnkly I'm not interested in the discussion of documents and 
> 	which doc contains what. I'm more interested in the technical 
> 	evaluation of a proposal. It seems like people are avoiding 
> 	this topic. 
> 
> 	Regards,
> 	Hesham
>

---

From: Phil Roberts <[email-masked]>
Date: Mon, 30 Jul 2001 10:40:25 -0400

> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Monday, July 30, 2001 10:23 AM
> On Mon, Jul 30, 2001 at 10:23:35AM -0400, Phil Roberts wrote:
> > I'm not sure what sort of problem it is, but would like to 
> know.  I'm
> > somewhat concerned about putting forth a proposal that does 
> cause this
> > sometimes.  It seems like it would be worthwhile to 
> determine whether there
> > is another way to perform smooth handovers that doesn't 
> create duplicates.
> 
> And just to be clear, the mobile wouldn't automatically 
> receive several
> copies all the time. There is a fairly small window where the mobile 
> could end up receiving dups. 

Right.

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Mon, 30 Jul 2001 17:46:21 +0200

Hello Phil

> Here is the general observation.  You are proposing bicasting 
> as a solution
> that
> solves only a part of the handover smoothing problem, that is 
> the potential
> loss
> of packets in flight between an HA or hierarchical MIP agent 
> and an FA or
> AR.

That's not totally correct and misses an important reason for bicasting.
If FMIP (let's take FMIPv6) is used without any bicasting, the MN
will receive a proxy advertisement a certain time before an L2 handoff
and it will send a F-BU. From that moment onwards, until the MN moves
to nAR it can't resume communication. The same thing is for FMIPv4.
Does that make sense? So the MN will stay without service for a certain
period. Instead, by using simultaneous bindings (which we've also
called bicasting) that period of service disruption can be avoided.
This is more than eliminating the loss of packets in flight between
HA or local HA and FA/AR while the MN is about to make the L2 handoff.

>  That's
> fine as far as it goes and it seems it should be made clear 
> that this is
> *all* it
> does.  It does not help in the general case of interruption 
> of flow between
> oFA/MN and
> nFA/MN.  I believe you agree to this below when you say the 
> examples I put
> forth were
> L2 specific.

Some comments on this above.
Of course we cannot get L3 to solve the case where the MN is
disconnected al L2.

> So here we need some kind of information that describes FA or AR
> behavior wrt duration of the handoff time and whether or not it's
> TCP traffic or something that is realtime traffic.

Happy to put something in describing the real-time/non real-time cases.
The idea was to leave this behaviour open and say the nFA MAY buffer
or MAY drop. We could give an example though.

> I agree with this, but I don't know how to do it.  Now we need to add
> to the decision matrix characteristics about the wired connectivity.

Well, I can agree with putting in some examples as above but we can't
design the system and take the implementor's place. So would some
examples be what you are looking for?

> But still, it doesn't take into account latency within the network.
> Whereas it seems that a receiving station might be able to make some
> intelligent decisions about when it is important to drop a 
> packet (because
> it arrived way too late), but now do you want the network in 
> between to get
> involved in the measurement and timing of these decisions? 

No measurement is involved by the network. Any buffering is put
in place by the implementor depending on the traffic, network etc.
That has to be done in any case depending on the application. 
I wasn't suggesting an on-the-fly calculation.

> OK, but how?  A packet arrives at the nFA.  How does the nFA 
> have any idea
> whether or not it needs to be buffered and then for how long, 
> or dropped?
> In
> this case it should be dropped, in the previous case it 
> should be dropped,
> and in the first case it should be sent.  But the only way I 
> know that is by
> knowing what the MN has already received.

If the jitter-smoothing buffer is put in nFA it will be used.
There's no decision on-the-fly. If instead it is deemed that
the gains in buffering are not worth the memeory/complexity
then we have the case where nFA always drops.

> But wait a second.  What do you mean by equal distance?  Number
> of hops, geographical distance?  It has to be transmission time.
> Is this another item we need to add to our decision matrix?

That's the wired connectivity which you had previously and I assumed
that was the same as transmission time. This would not be considered
in the case I described above, but would be part of the buffer
sizing calculation otherwise. So there's different ways of implementing
this.

Overall, you seem to want to understand the details of the buffer
calculation. It's good to discuss this and find any problems, but I
don't think we should document a formula how to calculate buffer
sizes. The people who know the L2 characteristics and the implementors
will know better. The point is that, and I've hopefully come across
with that, bicasting is useful and can work. Otherwise if I haven't
succeeded, too bad :(

> So I guess in summary, "I don't buy it," means I'm not convinced by
> your answers.  I've given some of my reasons why.

Hope I've answered some of the questions. What I haven't understood
yet is whether you think it can work but we need to study the details
or whether you think this doesn't work.
 
> What I would recommend instead of including bicasting in the 
> fast handoff
> drafts for v4 and v6 is a placeholder that describes 
> precisely what the
> problem
> is (of lost packets in flight) and that a solution needs to 
> be provided.
> The WG
> debates the possible solutions and puts those in a separate draft.

Well, the problem is not really lost packets in flight.
Anyway, this placeholder would have to be turned into a reference to
the new solution/s ASAP. If not, the FMIP drafts remain incomplete.
That is, they solve the handoff issue but introduce another period
of service disruption. I don't think we can assume that there will
be L2 solutions to this new gap.

> 
> Speaking as a working group chair now:
> 
> I'm doing a little work to find out whether a solution that introduces
> duplicate
> packets will be shot down by the IESG right off the bat.  It 
> seems wise to
> separate the fast from the smooth part, advance the fast, and 
> produce a
> solution
> for the smooth later.

Fast and smooth are tightly linked. So we cannot move Fast on without
having come to some solution for smooth. They should go hand in hand
through standards process, which is why I don't like the idea of
delaying bicasting/buffering for later.

Rgds
/Karim

---

From: Phil Roberts <[email-masked]>
Date: Mon, 30 Jul 2001 14:28:03 -0400

> Hello Phil

HI again,
 
> HA or local HA and FA/AR while the MN is about to make the L2 handoff.

I half agree with what you've said.  There is another case my description
didn't cover between the oAR and the nAR.  The F-BU
is the indication that the oAR should start forwarding packets to the nAR.
To
the extent that the MN can't come up on the nAR there is a disruption.  In
this
case you are suggesting bicasting to allow the oAR to also send on the old
link.
(I guess this means the F-BU is not a deterministic indication that the
mobile
is moving?  As an aside this is why I raised the issue of an L2 trigger
saying
the mobile is no longer reachable here.)

The devil is in the details of course.  It seems perhaps a strategy in this
case
is to have the local implementation handle the ambiguity it has on its local
link,
for those links on which there is ambiguity about the connectivity.

> examples be what you are looking for?

There are a few things I'm looking for.  One is some sense that this
could be made to work.  That's personal.  Maybe more examples would persuade
me.  I'd also like to explore what some other options are for smoothing.  I
see
the fast part of handoff as more decoupled from the underlying technology
than
the smoothing part and it seems it might be more worthwhile to explore how
what's done at L3 interacts with L2 for smoothing.  That's just my personal
opinion.

> I wasn't suggesting an on-the-fly calculation.

Good.

> then we have the case where nFA always drops.

It's hard for me to see how to implement a buffer at the nFA to handle
this case and if the nFA always drops then we're back to the original
case in which bicasting does not solve the problem.  (Packet arrives at
nFA and oFA while the MN is unreachable via either).  This makes me
think there might be another solution.

> sizing calculation otherwise. So there's different ways of 

Let me make one other point.  If the buffer size is dependent on the
wired topology does it have to be adjusted as the wired topology changes
(due to things like routing updates or congestion) or the AR/FA from
which the mobile is coming?

> with that, bicasting is useful and can work. Otherwise if I haven't

What I'd really like is to be persuaded that this solves the smoothing
problem
without introducing any new problems.  Right now I believe it doesn't solve
the
problem and does introduce new problems.

I don't know how serious the new problems are, but would like to.

> be L2 solutions to this new gap.

I would like a smoothing solution quickly as well.  Let's be careful.
I don't think FMIP introduces a gap that wouldn't be there with MIP already,
but is there something I'm missing?  I do think the gap is substantially
shortened by the fast techniques.  That is, after all, what was being
attempted.

> delaying bicasting/buffering for later.

I don't agree here.  I would like a smoothing solution also and would
like to see discussion on this progress.  But one of the important cases
could be L2 support for smoothing.  For such an environment, having fast
handoffs with MIP would be a big plus and there is not necessarily demand
for smoothing support.

Phil

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 31 Jul 2001 00:05:43 +0200

Hi Phil,

> they are not smooth seems to be confusing these two issues.
	=> I was giving an example of where the routing will fail due to 
	the anticipation process introduced in the draft. After all we're
	soving a routing problem and we donn't want to introduce another
	problem because of our solution The solution should not introduce
	new problems.

	I haven't read your other mail yet, still trying to catch up. 

	Regards,
	Hesham

> > 	which doc contains what. I'm more interested in the technical >

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 31 Jul 2001 00:15:41 +0200

George, 

	Just in case you missed my answer before :)

	The MN knows if it is in "danger" ofbicasting or not. IE. 
	it knows if TCP MAY be affected or not. If it has the 
	fix it doesn't matter, ifit doesn't it can request bicasting 
	depending on whether it has any TCP connections or not. 

	Note that I'm just going with the assumption that it is bad for TCP
	which is not proven. I've also pointed to an experiment that was 
	done on the impact of bicasting on TCP (+ve impacts). 

	Hesham

> Maybe you have missed this...please see my response to Mike on the same
> question...
> I feel like a broken record by there you go :-0
> 
> George
> P.S: in your question...what is "infrequent"??? the handoff? I do not think
> so....
> 
> From: George Tsirtsis [mailto:[email-masked]]
> Sent: Thursday, July 26, 2001 7:06 PM
> Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting
> 
> 
> Hi Mike,
> 
> I think you are making the point that - end hosts already deal with
> duplicate packets since this is a natural occurrence in the Internet today
> so bicasting should not be a problem -
> 
> The difference is that end nodes deal with duplicate packets up to a
> point...i.e.: up to 3 re-orderings/losses etc generating 3 dupacks in a row,
> before TCP starts having problems. The fact that TCP deals with 3 dupacks
> and not with 5 or 10 or 100 was an engineering choice that balances
> adaptivity and throughput with the chances of this happening in the Internet
> or they just picked a number from thin air...wouldn't know...was not here
> :-)
> 
> My argument is that bicasting, increases the chances of duplication on top
> of what the Internet naturally does and that could have bad effects if in
> widespread use. Say for example, due to natural re-ordering somewhere in the
> Internet, a node is about to receive 2 TCP acks, which TCP can actually deal
> with no problems. At the same time the MN's packets are duplicated (due to
> bicasting) at the receiving end, which results in the MN receiving 4 TCP
> acks! This forces TCP to half its window thinking that there must be
> congestion in the network and the packets do not get across which is clearly
> not the case!
> 
> So, the objections here are not about being able to "deal" with re-ordering
> as it naturally occurs but that we should not introduce mechanisms that
> artificially increase the chance duplicate acks.
> 
> Regards
> George
> Sent: Thursday, July 26, 2001 6:34 PM
> Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting
> 
> 
> Gary Kenward writes:
>  > > In the case of 1, the probability of a duplicate packet has nothing
>  > > whatsoever to do with the radio link. It is purely a matter of traffic
>  > > engineering in the wired network. So the probability of a duplicate
>  > > packet can be reduced by properly engineering the wired network. In
>  > > addition, the probability is likely to increase with the topological
>  > > distance between the new AR and the source of the bicast (simply
>  > > because, the more network a packet has to traverse, the more likely
>  > > it is that a congestion event may cause delay). Since engineering
>  > > of the wired network is largely under the network operator's control,
>  > > this problem is fairly straightforward to solve, though it may
>  > > require measures such as over provisioning.
>  > 
>  > Well, it takes more then over provisioning. You need to ensure
>  > the same number of hops between the bicasting source (the traffic
>  > bifurcation
>  > point if you will), and you also need to provide some guaranteed bounds
> on
>  > the delay at each hop after the bicasting source. *if* you want to ensure> 
> no
>  > duplicates
>  > at all at the receiver. This may seem like a definition of EF, but
>  > consider that the constraint is much more severe then that of EF. With
>  > EF the bound is on inter-packet delay and delay jitter for a single
> stream.
>  > With bicasting, the bound is on the arrival delay of two copies of the
>  > same packet that traverse different paths through N hops. The maximum
>  > delay difference, I believe, is one packet duration, T. Thus, the delay 
>  > difference bound at each hop must roughly be T/N (the relationship is
>  > not linear, but this gives a rough approximation). If the source of
>  > the delay is from queuing, then this would imply that there can be
>  > no other traffic following the same path. E.g. if a bicasted packet
>  > arrives at an AR and is queued behind a packet that is being served
>  > (note: served, not queued), from a different packet stream, then
>  > it receives a delay of roughly T/2.
> 
> I am very, very confused by all of this. Bicasting
> at the IP layer would merely result in duplicates
> which the transport/application layer would need
> to deal with. In fact, it already needs to deal
> with dups because IP packets are fairly regularly
> duplicated anyway. While it may require some
> specific tweaks to TCP (which I assume EIFEL
> attempts to provide), I see no reason why one
> would want to shield the receiver from this in the
> network, nor do I see any reason why it requires a
> difference in the per hop behavior in the tunneled
> traffic to AR new, or any consideration of number
> of hops, etc. The beauty of the end to end principal is
> that the receiver just adapts *regardless* of
> where the source of the jitter/loss/duplication/etc
> came from. Trying to deal with jitter hop-by-hop is akin
> to the general X.25 approach to transport which
> is if nothing else against the general IP
> philosphy of end to end transport. More
> pragmatically, dealing with jitter in the network
> will almost certainly yield a worse end to end
> delay as a single jitter buffer on the receiver.
> 
> 	 Mike
>    
> Sent: Monday, July 30, 2001 3:00 PM
> > So what's my position on this?  It seems that there are fairly obvious
> > cases in which bicasting introduces packet duplicates with potentially
> > unknown
> > effects in the network.  It doesn't seem the network agents will have the
> > information needed to prevent this from happening.
> 
> Just for clarification, duplicate packets already occur in the network.
> 
> So, why is the possibility of creating duplicates at the edges, during a 
> handoff - which is infrequent - now become a real problem, when they 
> already occur in the network without handoffs?
> 
> PatC

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 31 Jul 2001 02:43:21 +0200

> On Tue, Jul 31, 2001 at 01:43:40AM +0200, Hesham Soliman  (ERA) wrote:
> > 	=> Sorry if I appeared impatient, I didn't want to give 
> > 	that impression, the impression I wanted to give was
> > 	frustration because I think we're discussing secondary
> > 	issues (like which doc it should go in) or going around 
> > 	in circles on the technical side (like "it's bad for TCP", 
> > 	"but here's a fix", "but it's bad for TCP" !!!! ..etc)
> > 	I'm not blaming anyone, just hoping that we solve first
> > 	things first. 
> > 	- Acknowledge that there is a problem (already partially mentioned
> > 	  in FMIPv6)
> > 	- Agree on a solution 
> 
> Sure, but some folks will not agree on a solution because all they
> see is that bicasting doesn't work because of a problem with TCP that
> is being addressed. My intention is to try to get that issue out of
> the way so we can discuss actual solutions.
> 
	=> I hope you succeed ! I don't know what more can be 
	said about that. 

> It is rather difficult to discuss solutions, when folks cannot agree
> that one proposed alternatie is in fact a solution due to some
> perceived problem
> 
	=> Can't agree more. "Perceived" is the keyword here.

	Hesham

---

From: James Kempf <[email-masked]>
Date: Tue, 31 Jul 2001 08:20:11 -0700 (PDT)

Hesham,

>
>	For example, where is the analysis that Fast Handoffs 
>	will work at all ? More importantly where is the theoritical
>	analysis that contradicts the existing one in the draft ?
>

Appendix A of draft-kempf-beth-ipv6-01.txt in fact does contain
an analysis of FMIPv6. The numbers there are not encouraging.
This and the POST-REG work in FMIPv4 motivated the BETH work.

		jak