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

From: Tobias Küfner <[email-masked]>
Date: Mon, 19 Jan 2004 16:30:19 +0100

Hi,

can anybody give me some background information about this issue,
please? What has been the orgiginal motivation for the U bit? Wouldn't
it be a good idea to 'turn off' buffering for real-time applications
(seamless handover) and 'turn on' buffering for non-real-time
applications (lossless handover)?

Thank you.
Tobias

_____________
Tobias Küfner
Institute of Telematics, University of Karlsruhe, Germany

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of gabriel montenegro
> Sent: Tuesday, November 25, 2003 5:12 PM
> To: [email-masked]
> Subject: [Mipshop] [issue4] Delete or Keep U bits for buffering
> 
> 
> 
> 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
> 

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 19 Jan 2004 08:51:03 -0800

Hello,

It is a bad idea to turn off buffering for realtime applications
that want to get all of their packets.

Regards,
Charlie P.

Tobias K|fner wrote:

>Tobias K|fner

---

From: Tobias Küfner <[email-masked]>
Date: Wed, 21 Jan 2004 13:32:12 +0100

Hi,

of course, you're right. A lot of applications will benefit from
buffering packets during handoff. However there also exist applications
(e.g. realtime network games or maybe VoIP) which don't need to get all
their packets and which might perform better without having to handle
buffered/delayed packets. Don't you think so?

Best Regards
Tobias

> On Behalf Of Charles E. Perkins
> Sent: Monday, January 19, 2004 5:51 PM
> To: Tobias Küfner
> Cc: [email-masked]
> Subject: Re: [Mipshop] [issue4] Delete or Keep U bits for buffering
> 
> 
> Hello,
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 21 Jan 2004 09:09:03 -0800

There's another issue here.

I think basic RFC 2461 support includes a small buffer (Linux is three
packets), which is intended for the router to keep incoming packets around
until address resolution is complete, in the typical nonmobile case. This
could also serve in the case of FMIP as well. We've actually found in
experimental work that the 3 packet buffer provides good results, even for
real time traffic, in that it does not result in excessive ringing when the
packets are downloaded after the routing repair is complete (this is with a
20 ms interarrival time on the packet stream).

Is the intent of the U bit to also turn off basic ND buffering, or is it
just for more extensive buffering?

            jak

---

From: "Youn-Hee Han" <[email-masked]>
Date: Mon, 26 Jan 2004 19:44:47 +0900

RGVhciBhbGwsIA0KDQpJIGp1c3Qgc3VibWl0dGVkIGFuIGluZGl2aWR1YWwgSS1EIG9uIGEgbmV3IENvQSANCmNvbmZpZ3VyYXRpb24gJiBjb25maXJtYXRpb24gZm9yIEZNSVB2NiwgYXZhaWxhYmxlIGF0DQoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaGFuLW1pcHNob3AtbmNvYWNvbmYtZm1pcHY2LTAwLnR4dA0KDQpBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBuZXcgY2FyZS1vZiBhZGRyZXNzIChOQ29BKSBjb25maWd1cmF0aW9uIA0KYW5kIGNvbmZpcm1hdGlvbiBzY2hlbWUgZm9yIHRoZSBNb2JpbGUgSVB2NiBmYXN0IGhhbmRvdmVyIHByb3RvY29sDQooRk1JUHY2KS4gVGhlIGdvYWwgb2YgdGhpcyBwcm9wb3NhbCBtYWtlcyBGTUlQdjYgYWRkcmVzcw0KY29uZmlndXJhdGlvbiBhbmQgY29uZmlybWF0aW9uICd2ZXJ5IGZhc3QnIGFuZCBpdHMgY29uZmlybWF0aW9uDQpyZXN1bHQgJ2Fsd2F5cyBzdWNjZXNzZnVsJy4gVGhlIHByb3Bvc2VkIHNjaGVtZSBjYW4gYmVjb21lIGENCnN1cHBsZW1lbnRhcnkgZnVuY3Rpb24gaW1wbGVtZW50ZWQgaW4gb25seSBub2RlcyB3aGljaCBwbGF5IGEgcm9sZSBvZg0KbmV3IGFjY2VzcyByb3V0ZXIgaW4gRk1JUHY2Lg0KDQpJIGFtIGxvb2tpbmcgZm9yd2FyZCBnZXR0aW5nIHlvdXIgY29tbWVudHMgb24gdGhpcyBkb2N1bWVudC4NCkJlc3QgcmVnYXJkcywNCg0KLSBZSA==_______________________________________________Mipshop mailing [email-masked]://www1.ietf.org/mailman/listinfo/mipshop