Subject: [mobile-ip] Some facts and motivations for bicasting

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 26 Jul 2001 17:23:58 +0200

Hi, 

In order to help with the discussion and have some understanding 
for the motivation behind bicasting before we make a call on whether
it should or should not be in the FMIPv6 draft, I'd like to put down
a summary of the motivations here so people can consider these 
reasons. All of these were mentioned by Karim and others and 
you can find them also in the bicasting draft.

- The FMIPv6 draft introduces the concept of anticipation. A MN 
  gets to know about the anticipated AR (nAR) before it actually 
  moves there. The MN sends an F-BU to direct its traffic to the 
  nAR. 

- In the scenario above, it is not possible for the MN to know exactly
  when it will detach from the current AR. 

Some questions here: 
 
1. Forwarding from oAR:
    When does the oAR start forwarding traffic ? As soon as it 
    receives the BU ? If so what if the MN is still attached to it ?
    what if the handover fails and the MN remains attached to 
    the current AR ? 
    If the oAR forwards immediately to the nAR delays are 
    introduced even if the packets are buffered at the nAR. 
    If it waits then how long does it wait for ?
    Assuming that the oAR will know when the MN detaches
    is not acceptable. This is an L2-specific feature and is 
    not applicable to many cases.

2. What if the MN moves to the nAR and then moves back 
    (ping pong) ? 
    There is no solution in the current draft for this. 

Bicasting solves the above two cases. Bicasting does NOT
mean that the MN receives all packets twice. More info is 
in the draft.

Concerns regarding bicasting:

- TCP concerns: This is solved by Eifel. Eifel was NOT developed
  for bicasting but it does solve the problem. Since the request 
  (in the case where the MN sends the BU) comes from the MN, 
  the MN can decide whether it can request or not based on its
  own design decisions. 

- Header compression and context transfer: Bicasting has nothing 
  to do with these issues. IF CT is needed for header compression
  it will be done in the right WG. There is no difference here whether
  you bicast or unicast.

As a side note, Ralf Schmitz from NEC labs presented some test
results for bicasting and TCP in IPCN conference in Paris last May. 
He showed that TCP performance has improved when using bicasting. 
Unfortunately I don't have a soft copy, but you can buy the papers if 
you're really interested :)
http://www.upperside.fr/ipcn01/ipcn01pro.htm 

Finally, simultaneous bindings have been in 2002 for years now
and are currently in the FMIPv4 draft. I fail to see why v6 should be
any different. 

Regards,
Hesham