Subject: [Mipshop] [issue4] Delete or Keep U bits for buffering

From: gabriel montenegro <[email-masked]>
Date: Tue, 25 Nov 2003 16:12:28 +0000

This has been entered in the issue tracker as issue 4.

owner: gabriel montenegro <[email-masked]>:

category: Technical
draft: draft-ietf-mipshop-fast-mipv6
priority: Should fix
status: Pending
title: Delete or Keep U bits for buffering

Need to resolve whether to keep or delete the U bits which appear in the
RtSolPr and HI messages.

Some email exchanges follow:

gab wrote:

>>        Can the 'U' bit be abused? Why wouldn't an MN not turn it
>>        on *always*. In which case why even have a bit? I.e. is this
>>
>
>
> If the MN can send FBU from the previous link, it does not have
> to turn it on. Buffering will be done at NAR in such a case

So for buffering to be correctly provided, the MN does not need
to get involved in this case.... [see below]

>>    something that can be provided at the discretion of the PAR
>>        without any input from the MN? If so instead a bit issue
>>        a recommendation on the PAR that it provide this service if
>>        at all possible. One question, why would buffering be provided if
>>        the LLA of the new point of attachment is a wildcard?
>
>
>
> Even when the wildcard is supplied, buffer-and-forward allows the
> MN to reduce packet loss in the event that it handovers to any one
> of the target access points without anticipation.

[from above] ...nor does the MN need to be involved in this case.
So is there an occasion in which for buffering to be correctly
provided it MUST be requested by the MN? If not, why even have the
U bit in the RtSolPr (RtSolPrAdv) message? I understand why it makes
sense in the HI, but am wondering about the RtSolPrAdv.

-gabriel 

Rajeev wrote:

gabriel montenegro wrote:
>>> >
>>> > Even when the wildcard is supplied, buffer-and-forward allows the
>>> > MN to reduce packet loss in the event that it handovers to any one
>>> > of the target access points without anticipation.
>
>>
>> [from above] ...nor does the MN need to be involved in this case.
>> So is there an occasion in which for buffering to be correctly
>> provided it MUST be requested by the MN? If not, why even have the
>> U bit in the RtSolPr (RtSolPrAdv) message? I understand why it makes
>> sense in the HI, but am wondering about the RtSolPrAdv.
>>

Buffering _can_ be provided without the MN requesting it. The question
is should the MN have the option of requesting it. I recognize that with NAR
doing buffering, the MN is not involved in requesting buffering. For symmetry,
we either have the 'U' bit in both the cases, or we should drop it. What do
others
think ?

-Rajeev

James wrote:

I think limiting the amount of complexity in a protocol is a good idea and I
can't see any basis upon which an MN could make a decision about whether
buffering was or was not a good idea, since the MN can't know nor can it
easily find out what the access network topology looks like, which would
provide it information about whether buffering was a good idea. Therefore, I
think the 'U' bit should be dropped.

            jak

Youn-Hee wrote:

I'd like to vote this. Actually, buffering issue seems to be no big issue
in current FMIPv6 standard process. But, when I read current 
00-version, there was some doubts about FMIPv6's buffering 
mechanism.

Firstly, I don't agree 'U' bit in 'RtSolPr'. Many operators would like 
to make FMIPv6 run as predictive mode, because they know the 
predictive mode is better. The predictive handover requires MN 
to receive PrRtAdv and FBAck prior to movement. So, MN would
preserve its connection with PAR (like Lezy handover) and receive
packets come from PAR as much as possible. During this time, IMO,
buffering is needless. 

And, the exchange of RtSolPr and PrRtAdv will take very short time.
So, IMO, at least FBU can be sent to PAR prior to movement though
MN moves fast (but, I don't know how fast MN moves to miss delivery
of FBU to PAR). IMO, the time for PAR to receive FBU seems to be
right buffering time. 

When PAR receive FBU, it sends HI to NAR. The main goal of HI is
the prospective NCoA confirmation. So, HAck is sent to MN in 
response of HI and it has the result of confirmation. IMO, Not until 
receving the successful result of confirmation, PAR should not tunnel
packets to the NCoA. So, PAR should buffer packets until receiving 
HAck. How do you think about this?

But, I am not advocating 'U' bit in 'FBU' instaed of 'RtSolPr'. 
I don't think that buffering is not one which MN should deterimine. 
This is a supplementary function which router may voluntarily support.

- Youn-Hee (YH).
_____________________________________________________
Mipshop issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mipshop/issue4>
_____________________________________________________

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