Subject: [Mipshop] FMIPv6 - Packet Loss

From: Subba Reddy <[email-masked]>
Date: Thu, 08 Sep 2005 09:35:20 +0530

Hi,

    I have few questions related to buffering.

    From section 5.3 of spec,

"   Handover involves link switching, which may not be exactly
   coordinated with fast handover signaling.  Furthermore, the arrival
   pattern of packets is dependent on many factors, including
   application characteristics, network queuing behaviors, etc.  Hence,
   packets may arrive at the NAR before the MN is able to establish its
   link there.  These packets will be lost unless they are buffered by
   the NAR.  Similarly, if the MN attaches to the NAR and then sends an
   FBU message, packets arriving at the PAR will be lost unless they are
   buffered.  This protocol provides an option to indicate a request for
   buffering at the NAR in the HI message.  When the PAR requests this
   feature (for the MN), it SHOULD also provide its own support for
   buffering."

    Does the last sentence means " When the PAR requests this feature (for the MN),
    *PAR* SHOULD also provide its own support for buffering"?

    If Yes, When the PAR will start buffering the packets?

Thanks & Regards,
Subba Reddy

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "jaehwoon" <[email-masked]>
Date: Thu, 8 Sep 2005 13:57:47 +0900

Hi!

Based on my understanding about FMIPv6,

(1) Proactive mode
     PAR start buffering when receiving FBU from MN.

(2) Reactive mode
     PAR also start buffering when receiving FBU from MN.
     However, before receiving FBU from MN, there may be some packet loss.
     There exists a period that packet loss occurs, from the time that MN
     disconnet the connection with PAR, till the time that MN connects with NAR and
     send FBU (is encapsulated in FNA) and the FBU arrives at the PAR.

It's just my opinion.

jaehwoon
  ----- Original Message ----- 
  From: Subba Reddy 
  To: [email-masked] 
  Sent: Thursday, September 08, 2005 1:05 PM
  Subject: [Mipshop] FMIPv6 - Packet Loss

  Hi,

  Thanks & Regards,
  Subba Reddy

------------------------------------------------------------------------------

---

From: "Hongseok, Jeon" <[email-masked]>
Date: Thu, 8 Sep 2005 15:50:51 +0900

Hi Reddy,

Actually, FMIPv6 spec. does not describe exactly when packet forwarding from PAR to MN (or NAR) 
and buffering packets for MN begin. I think we have to use of Link Down (L2 trigger) event and HAck message 
for the purpose of the decision of packet forwarding and buffering point. 

In general, Link Down event over PAR indicates PAR buffer the packets for MN specified in the Link Down, 
and HAck message let PAR start forwarding the packets to MN's NCoA (or NAR). However, a final decision is 
made according to the order in which Link Down and HAck occur in order to decrease the size of buffer memory 
and handover latency.               

If Link Down event is generated over PAR prior to HAck message, PAR starts buffering packets for MN upon 
getting the Link Down and forwards the buffered packets to MN (or NAR) when receiving HAck. Otherwise, (when
PAR receives HAck message prior to Link Down event) PAR defers the packet forwarding until Link Down event is generated. 
In this case, packet buffering in PAR may not be necessary. 

Regard,
Hongseok
  ----- Original Message ----- 
  From: Subba Reddy 
  To: [email-masked] 
  Sent: Thursday, September 08, 2005 1:05 PM
  Subject: [Mipshop] FMIPv6 - Packet Loss

  Hi,

  Thanks & Regards,
  Subba Reddy

---

From: "jaehwoon" <[email-masked]>
Date: Thu, 8 Sep 2005 17:03:31 +0900

Hi!

If MN connects the PAR via Access point (AP), 
then PAR may not receive the link down event.

Regards,

Jaehwoon Lee
  ----- Original Message ----- 
  From: Hongseok, Jeon 
  To: Subba Reddy ; [email-masked] 
  Sent: Thursday, September 08, 2005 3:50 PM
  Subject: Re: [Mipshop] FMIPv6 - Packet Loss

  Hi Reddy,

  Regard,
  Hongseok
    ----- Original Message ----- 
    From: Subba Reddy 
    To: [email-masked] 
    Sent: Thursday, September 08, 2005 1:05 PM
    Subject: [Mipshop] FMIPv6 - Packet Loss

    Hi,

    Thanks & Regards,
    Subba Reddy

----------------------------------------------------------------------------

---

From: Martin André <[email-masked]>
Date: Thu, 08 Sep 2005 11:37:44 +0200

Hi,

>      PAR start buffering when receiving FBU from MN.

Actually the proactive mode do not require the PAR to start buffering in 
order to avoid packet loss. The tunnel between PAR and NCoA would 
already be set up when the MN leaves and arriving packets will be sent 
through the tunnel and buffered at the NAR until it gets notified of the 
MN's presence.

>      send FBU (is encapsulated in FNA) and the FBU arrives at the PAR.

The reactive mode is much more complicated to handle with. Here the PAR 
will have to predict the MN's movement and start buffering before the MN 
actually leaves. The big question is to know when the MN'll leave. As 
you mentioned, starting buffering upon FBU receipt is not the answer.
One would suppose that the MN will leave after having performed 
neighborhood discovery, this is what RFC4068 suggests (section 4):

    When further protocol action is necessary, some implementations MAY
    choose to begin buffering copies of incoming packets at the PAR.  If
    such FIFO buffering is used, the PAR MUST continue forwarding the
    packets to PCoA (i.e., buffer and forward).  Such buffering can be
    useful when the MN leaves without sending the FBU message from the
    PAR's link.  The PAR SHOULD stop buffering after processing the FBU
    message.  The size of the buffer is an implementation-specific
    consideration.

This solution may not appear very effective from an implementor's point 
of view because this means that the PAR buffers and forwards every 
packets for each attached MN. Effectively, the spec recommends to send 
an RtSolPr message after attachment to a link (right after having 
performed router discovery). A solution would be to distinguish between 
the RtSolPr that say "I just arrived" and the one that say "I'm planning 
to leave". Maybe adding a flag in the RtSolPr in which the MN can ask 
for buffering on PAR's side would help.

Any comments?

Martin

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 08 Sep 2005 20:02:50 +0200

Martin André wrote:

> to leave".

Sounds interesting idea to have RtSolPr flag "I'm planning to leave" in
order to PAR to know when to start buffering.  But then again, between
the moment PAR receives RtSolPr and the moment MN actually puts its link
down all the packets are buffered at PAR instead of being delivered to
MN; that time lapse is not negligible because it involves at least the
time to wait for PrRtAdv; so this may be seen as actually lengthening
the handover time, no?

Alex

---

From: "Hongseok, Jeon" <[email-masked]>
Date: Fri, 9 Sep 2005 09:09:18 +0900

Hi Jaehwoon,

Maybe, we need some protocol which delivers L2 trigger from AP to AR.
That is necessary in Network initiated handover in FMIPv6 and LLH Post-registration method. 
I think remote MIH signaling prepared by IEEE 802.21 can be used for the purpose.

Regards,
Hongseok   

  ----- Original Message ----- 
  From: jaehwoon 
  To: Hongseok, Jeon ; Subba Reddy ; [email-masked] 
  Sent: Thursday, September 08, 2005 5:03 PM
  Subject: Re: [Mipshop] FMIPv6 - Packet Loss

  Hi!

  Regards,

  Jaehwoon Lee
    ----- Original Message ----- 
    From: Hongseok, Jeon 
    To: Subba Reddy ; [email-masked] 
    Sent: Thursday, September 08, 2005 3:50 PM
    Subject: Re: [Mipshop] FMIPv6 - Packet Loss

    Hi Reddy,

    Regard,
    Hongseok
      ----- Original Message ----- 
      From: Subba Reddy 
      To: [email-masked] 
      Sent: Thursday, September 08, 2005 1:05 PM
      Subject: [Mipshop] FMIPv6 - Packet Loss

      Hi,

      Thanks & Regards,
      Subba Reddy

--------------------------------------------------------------------------

---

From: Subba Reddy <[email-masked]>
Date: Fri, 09 Sep 2005 09:42:34 +0530

Hi Martin,

> for buffering on PAR's side would help.

I think, sending FBU from NAR's link happens in the cases where MN don't
know
that "it is going to leave". If MN can know that "it is going to leave", it
can send FBU
itself (ofcourse, if it knows prefix).

Thanks & Regards,
Subba Reddy

---

From: Martin André <[email-masked]>
Date: Fri, 09 Sep 2005 11:56:49 +0200

Hi Subba,

> itself (ofcourse, if it knows prefix).

I agree with that. Generaly reactive handover is not planned, otherwise 
it could have been predictive.

Nevertheless, a MN may not have up to date information about nearby APs 
by the time it receives a "decreasing signal" trigger and may think it 
has enought time to perform an RtSolPr/PrRtAdv exchange before sending 
an FBU. The MN may want to ensure it won't lose packets during this 
operation and could set a flag in RtSolPr when it considers there is a 
risk. I didn't formulate well the meaning of the flag. In my though it 
was more like "I might lose connectivity, please help me" instead of 
"I'm planning to leave".

Anyway, that was just a though in reaction to the following (part 5.3 of 
RFC4068):

    This protocol provides an option to indicate a request for
    buffering at the NAR in the HI message.  When the PAR requests this
    feature (for the MN), it SHOULD also provide its own support for
    buffering.

On one hand adding support for buffering on NAR is quite easy and very 
useful and on the other hand adding support for buffering on PAR may be 
very painful. The SHOULD may be too strong.

Martin

---

From: "jaehwoon" <[email-masked]>
Date: Fri, 9 Sep 2005 19:06:21 +0900

Hi!

My comment is in line.

> through the tunnel and buffered at the NAR until it gets notified of the

In order for NAR to start buffering, NAR has to know what it buffers.
In order to do that, PAR should provide the MN's information to NAR by using HI message.
That is, PAR should buffer the packets for MN until NAR sets up tunnel and buffer for MN.
Hack message is to notify to PAR that NAR sets up tunnel and assigns buffer for NCoA.
Moreover, one purpose of HI is to check DAD.
(Even though it can be rare, assume that DAD check is considered as failed.)
So, I'm not sure if PAR does not require buffering.

> for buffering on PAR's side would help.

I also think that it is difficult how to know when MN leaves.
And I also think that it's good if there is a good solution to know how.
However, MN is not a network device but a host device.
To send RtSolPr does not mean that MN really wants to leave.
(Actually, how to know that MN really wants to leave?)
One can use RtSolPr message just to check DAD for NCoA.
Moreover, MN may not move to NAR just after sending RtSolPr.
PAR cannot know if MN is about to leave.
So, I'm not sure how to know that.

Any commnets?

Jaehwoon

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 14 Sep 2005 10:42:43 -0700

Hongseok, Jeon wrote:
> and buffering packets for MN begin. I think we have to use of Link Down 

The packet forwarding from PAR begins upon processing FBU.

Buffering at NAR begins upon processing the HI message.

PAR MAY keep a small buffer at all times. This can be useful when
the MN leaves without sending FBU from the previous link. So, even
if the FBU is received from NAR's link, buffered pacekts can be 
forwarded. This feature can be considered implementation-dependent.
I wonder if we should state something as such explicitly?

-Rajeev

> (L2 trigger) event and HAck message
> and HAck message let PAR start forwarding the packets to MNs NCoA (or 
> NAR). However, a final decision is
> PAR receives HAck message prior to Link Down event) PAR defers the 
> packet forwarding until Link Down event is generated.
>     *From:* Subba Reddy <mailto:[email-masked]>
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Sent:* Thursday, September 08, 2005 1:05 PM
>     *Subject:* [Mipshop] FMIPv6 - Packet Loss
> 
>     Hi,
>      
> ------------------------------------------------------------------------
>

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 14 Sep 2005 10:54:14 -0700

> I wonder if we should state something as such explicitly?

As Andre pointed out.. :-)

 From Section 4:

"When further protocol action is necessary, some implementations MAY
    consideration. "

---

From: Subba Reddy <[email-masked]>
Date: Thu, 15 Sep 2005 10:10:14 +0530

Hi Rajeev,

> forwarded. This feature can be considered implementation-dependent.

True.

But, from section 5.3 of spec
"
   Handover involves link switching, which may not be exactly
   coordinated with fast handover signaling.  Furthermore, the arrival
   pattern of packets is dependent on many factors, including
   application characteristics, network queuing behaviors, etc.  Hence,
   packets may arrive at the NAR before the MN is able to establish its
   link there.  These packets will be lost unless they are buffered by
   the NAR.  Similarly, if the MN attaches to the NAR and then sends an
   FBU message, packets arriving at the PAR will be lost unless they are
   buffered.  This protocol provides an option to indicate a request for
   buffering at the NAR in the HI message.  When the PAR requests this
   feature (for the MN), it *SHOULD* also provide its own support for
   buffering.
"

*SHOULD* may need to be modified.

Thanks & Regards,
Subba Reddy

---

From: "Hongseok, Jeon" <[email-masked]>
Date: Fri, 16 Sep 2005 16:52:03 +0900

Hi Rajeev, 

I need  more clarification of your description, 
" > The packet forwarding from PAR begins upon processing FBU.".

The FBU processing includes the HI/HAck exchanges ?    

I think the right point for packet forwarding from PAR need to begin
after processing HAck. That means after confirming the 'ACK' about the 
proposed NCoA from the NAR.

In case of address confliction, if the packet forwarding is started upon receiving 
the FBU, then some packets' outer address of the forwarded packet can be 
different from the address that is newly proposed address from NAR. 

Therefore, those can not reach to MN.

Such a situation happens also when NAR tries to support host routing for 
PCoA instead of assigning NCoA.

Am I misunderstanding something here ?
I think forwarding point needs to be clarified.

Regards, 
Hongseok

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Sep 2005 10:24:53 -0700

> The FBU processing includes the HI/HAck exchanges ?  

HI/HAck is a SHOULD.

You should do that if you are concerned with misdirecting the traffic.

-Rajeev