Subject: [multimob] Fast Handover Solutions

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 12 Nov 2012 23:28:54 +0100

Hi all,

after the - somewhat uninformed discussion at IETF85 - chairs asked me 
to restate requirements of a "fast handover solution" for Multicast 
Mobility.

Here they are:

  (i) Handover should be fast (this is only true for a direct pMAG/AR to 
nMAG/AR solution such as 
http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast).

  (ii) Multicast handover should be fully synchronized with unicast 
handover (otherwise unicast and multicast states diverge as is a 
well-known issue for the RAMS-approach, i.e., 
https://tools.ietf.org/html/draft-ietf-multimob-fast-handover).

  (iii) Multicast handover solutions should tightly integrate with 
unicast handover (only 
http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast 
integrates with PFMIPv6 and FMIPv6).

  (iv) Handover management should reuse standard mobility and multicast 
protocol operations for easy implementation and deployment 
(http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast 
introduced the use of standard IGMP/MLD records for context description 
in transfer, which has been copied several times).

  (v) Multicast handover management should integrate ASM and SSM, as 
well as IPv4 (IGMP) and IPv6 (MLD), which is only provided by 
http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast.

Based on these facts, chairs and AD proclaimed to re-decide on future 
paths for Multimob fast handover solutions.

Cheers,

Thomas
-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 15 Nov 2012 18:56:11 +0100

Hi Thomas, all,

Please see some comments inline below.

> to restate requirements of a "fast handover solution" for Multicast 

I don't recall the chairs asking you to restate the requirements of a
"fast handover solution", and the minutes do not reflect that either.
Our AD asked the WG to document the requirements of the different
solutions the WG is working on, as well as the feedback obtained from
operators interested in multimob work.

Actually, the WG already has a WG document for the fast handover
solution milestone, and during initial discussions and the adoption
process, we did have discussions on different aspects of how a fast
handover solution should operate and the different requirements it
should meet. There have been several reviews of the WG document and it
captures feedback from the WG.

> Here they are:

This list, IMHO, is not complete. For example, one critical aspect that
has been discussed several times is how generic the solution is and what
requirements it imposes on the different involved entities, as for
example the need of layer-2 triggers on the mobile node.

> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast).

The handover speed will highly depend on the network topology in place.
It cannot be generally stated that direct communication will always be
faster than MAG to LMA communication. In fact, taking into account
typical operative networks, an strict hierarchical topology is commonly
deployed where the communication among different elements located in
different access networks pass through central elements, using an star
topology. Considering that a MAG could be able to serve a huge number of
radio accesses, the more logical trend could be to deploy separated
MAGs, without direct connectivity capabilities. Additionally, as
previously discussed on this mailing list, you should note that the
reactive case for FPMIPv6 is extremely harmful from the multicast
handover delay perspective, as it needs to firstly register the MN and
resolve the MLD Query process of RFC6224 to trigger the reactive
mechanism afterwards. There is for sure no improvement regarding
RFC6224. Furthermore, the dependency on the radio part (for layer-2
trigger capabilities) definitely limits the potential benefits that your
proposal could provide.

> https://tools.ietf.org/html/draft-ietf-multimob-fast-handover).

The adopted WG document draft-ietf-multimob-fast-handover (previously
aka RAMS, now SIAL) is totally synchronized with the unicast handover,
up to the point that it is triggered by the registration and/or
de-registration messages of the unicast handover. It is difficult to
achieve a better integration. In the proactive case, the de-registration
message for unicast handover sent by the pMAG conveys the multicast
membership subscription context for the moving MN. In the reactive case,
the registration message for the MN attaching to the nMAG triggers the
process, and the response to the registration PBU conveys the multicast
membership subscription context. Do you really think these are not
synchronized processes?

BTW, what is the "well-known" issue you refer to?

> integrates with PFMIPv6 and FMIPv6).

The key point here is to be *integrated* with PMIPv6 in a *general* way.
The integration of SIAL with PMIPv6 is ensured as described above.
Furthermore, it is general because it does not impose the necessity of
additional layer-2 capabilities in the MN to work. This does not happen
with other solutions, including yours.

Additionally, this has been discussed already in the WG. Several
individuals, such as Marco, expressed that unicast and multicast
handovers have different considerations. The WG consensus was to not to
specify in the adopted document a solution bound to a unicast handover
optimization solution.

> in transfer, which has been copied several times).

draft-ietf-multimob-fast-handover incorporated the use of the standard
multicast address record format as result of the WG feedback.

> http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast.

Since the SIAL solution deals with multicast membership subscription
context transfer, no issues relate to ASM and SSM. Regarding the IPv4
treatment, we thank you for pointing this out and this is going to be
addressed in the next revision of the document, as we discussed during
the Atlanta meeting. We don't foresee any significant issue on adding
that support, and we of course welcome any contribution from you or any
other WG member on this aspect.

> paths for Multimob fast handover solutions.

Again, based on what I recall, that seems to match what is captured in
the minutes, what was discussed is that the AD would check with the
chairs the process of the adoption call of
draft-schmidt-multimob-fmipv6-pfmipv6-multicast. I don't quite see how a
formal process revision (decision of the chairs on a WG adoption
document) relates with your e-mail.

Thanks,

Carlos

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 15 Nov 2012 20:10:57 +0100

Hi Carlos,

just a short answer: Chairs asked me in personal communication to send 
these requirements.

For the rest:

We have had lengthy discussions over months on all the subjects, on-list 
and off-list, mentioning all types of pro's and con's. I don't want to 
repeat this.

We finally agreed (with chairs) off-list to adopt both drafts as 
experimental ... but then some people behaved differently from what they 
had said earlier.

My view on the general situation is that there are two kinds of 
reasonable work for Multimob

  (i) Basic enabling of PMIP multicast
  (ii) Convincing coverage of the solution space in relevant scenarios

(i) will be done by Multimob with the Base + MLD RFCs and the source 
solution.

Ad (ii), my impression is that Multimob is not really doing a decent 
job. In fact, I have severe doubts that any of the work on track will be 
of any value to anyone.

So I believe we should start thinking about closing Multimob.

Cheers,

Thomas

--

---

From: Stig Venaas <[email-masked]>
Date: Thu, 15 Nov 2012 15:43:26 -0800

Hi

> just a short answer: Chairs asked me in personal communication to send

I don't recall that, but happy to see them posted here.

> experimental ... but then some people behaved differently from what they

I don't recall that either.

> So I believe we should start thinking about closing Multimob.

We should finish the existing charter items, but I also think we need to
consider seriously whether it is worth adding new charter items. I feel
when we've completed the current items we've pretty much solved the more
obvious issues. Once PMIP with multicast gets more deployment it can be
reconsidered whether more IETF work is needed. I think it's best to do
the DMM multicast work in DMM. I'm not necessarily saying that multimob
should be closed any time soon, but we do need to at least have this
discussion. It is a natural part of the rechartering discussion.

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 16 Nov 2012 00:52:34 +0100

Hi Stig,

> I don't recall that, but happy to see them posted here.

Well, this was you in Atlanta in an oral discussion with Gorry.

> I don't recall that either.

This was Behcet in an Email discussion with Marco, Carlos & Carlos.

Cheers,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 16 Nov 2012 01:22:25 +0100

Hi again Stig,

on Multimob evaluation, please see inline:

On 16.11.2012 00:43, Stig Venaas wrote:

> obvious issues.

I would already question the last observation.

Multimob has moved into the complex domain of optimization by protocol 
extensions. To be successful in this area requires

  (a) a systematic exploration of the solution space
  (b) identification of superior solutions that are convincing to those 
who deploy

After the (inconsistent) rechartering, Multimob has neither acted 
systematically in any visible way, nor at superior quality. The 'fast 
handover disaster' is only one example were the group made random 
choices for solutions that are barely sound.

My personal impression is that people see Multimob just as a place were 
it is worthwhile fishing for an RFC number (sure, we also want to get 
documents published, but not on the price of humiliation), without even 
caring whether their proposals are implementable by reasonable means.

This has grown worth and worth. My impression from the Atlanta meeting 
was that we have reached a state where any technical argument is 
completely useless in Multimob and a waste of mental resources.

Cheers,

Thomas

>Once PMIP with multicast gets more deployment it can be

--

---

From: Stig Venaas <[email-masked]>
Date: Thu, 15 Nov 2012 23:56:08 -0800

Hi

> Well, this was you in Atlanta in an oral discussion with Gorry.

Right, I remember we discussed about requirements. I don't
remember exactly about posting them, but it certainly is a
good idea.

> This was Behcet in an Email discussion with Marco, Carlos & Carlos.

OK. Ideally we should as a group evaluate the proposals and pick the
one that we believe best fits the requirements, or maybe another
solution. Coming up with 2 solutions is not that good, unless we
believe there really is a need for 2 solutions. But it may be an
option.

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 19 Nov 2012 17:09:14 -0600

Hi Thomas,

It seems that these requirements are for

draft-schmidt-multimob-fmipv6-pfmipv6-multicast

and not for
draft-ietf-multimob-fast-handover.

What do you think?

Regards,

Behcet

On Mon, Nov 12, 2012 at 4:28 PM, Thomas C. Schmidt
<[email-masked]> wrote:
> Hi all,
>
> after the - somewhat uninformed discussion at IETF85 - chairs asked me to
> restate requirements of a "fast handover solution" for Multicast Mobility.
>
> Here they are:
>
>  (ii) Multicast handover should be fully synchronized with unicast handover
> (otherwise unicast and multicast states diverge as is a well-known issue for
> the RAMS-approach, i.e.,
>  (iii) Multicast handover solutions should tightly integrate with unicast
> handover (only
> introduced the use of standard IGMP/MLD records for context description in
> transfer, which has been copied several times).
>
>  (v) Multicast handover management should integrate ASM and SSM, as well as
> IPv4 (IGMP) and IPv6 (MLD), which is only provided by
> Based on these facts, chairs and AD proclaimed to re-decide on future paths
> for Multimob fast handover solutions.
>
> Cheers,
>
> Thomas
> --
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 20 Nov 2012 01:27:45 +0100

Hi Behcet,

these requirements are for a fast handover solution, i.e., a protocol 
that operates a *handover* in a *fast* manner.

I agree that draft-ietf-multimob-fast-handover does not meet the 
requirements, but had written earlier on the list that the name of this 
draft is misleading in two ways: (i) draft-ietf-multimob-fast-handover 
is not a fast handover solution, and (ii) the name "fast handover" is 
tied to RFC5568/RFC5949-like schemes for good reasons.

Cheers,

Thomas

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 26 Nov 2012 15:46:54 -0600

On Mon, Nov 19, 2012 at 6:27 PM, Thomas C. Schmidt
<[email-masked]> wrote:
> Hi Behcet,
>
> these requirements are for a fast handover solution, i.e., a protocol that
> operates a *handover* in a *fast* manner.
>
> draft is misleading in two ways: (i) draft-ietf-multimob-fast-handover is
> not a fast handover solution, and (ii) the name "fast handover" is tied to
> RFC5568/RFC5949-like schemes for good reasons.
>

The draft title contains ... handover optimization ... and it reflects
its content.
We asked for this WG draft name because of the charter item to which
it corresponds.

I think this clarifies your confusion.

Regards,

Behcet

>>> handover
>>> unicast
>>> in

---

From: "Rajeev Koodli (rkoodli)" <[email-masked]>
Date: Tue, 27 Nov 2012 00:07:30 +0000

Hi Behcet,

On 11/26/12 1:46 PM, "Behcet Sarikaya" <[email-masked]> wrote:

>>that
>>is

Sorry, which charter item has "fast-handover"?
Could you clarify?

Thanks.

-Rajeev

>>>> (otherwise unicast and multicast states diverge as is a well-known
>>>>issue
>>>> for
>>>> the RAMS-approach, i.e.,
>>>>well
>>>> as
>>>> ° Hamburg University of Applied Sciences                   Berliner
>>>>Tor 7
>>>> °
>>>> ° Dept. Informatik, Internet Technologies Group    20099 Hamburg,
>>>>Germany
>>>> °
>>>> ° http://www.haw-hamburg.de/inet                   Fon:
>>>>+49-40-42875-8452
>>>> °
>>>> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax:
>>>>+49-40-42875-8409
>>>> °

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 27 Nov 2012 11:24:33 -0600

Hi Rajeev,

I checked again.
The charter item is about PMIPv6 handover optimizations, not on fast handover.

The draft name should have been handover-optimizations not fast-handover.

Sorry about that because I had suggested this draft name.

Without realizing that it would cause so much trouble.

I repeat here again, the draft title did not change and the draft
content is reflected in the title. This is the most important thing.

Regards,

Behcet

On Mon, Nov 26, 2012 at 6:07 PM, Rajeev Koodli (rkoodli)
<[email-masked]> wrote:
>>>Germany °
>>>+49-40-42875-8452 °
>>>+49-40-42875-8409 °

---

From: "Rajeev Koodli (rkoodli)" <[email-masked]>
Date: Tue, 27 Nov 2012 18:19:27 +0000

Thanks for checking.

To avoid the confusion, kindly rename the draft appropriately.
The draft title and the draft name should be consistent, and not mislead,
as it does now.

-Rajeev

On 11/27/12 9:24 AM, "Behcet Sarikaya" <[email-masked]> wrote:

>>>> not a fast handover solution, and (ii) the name "fast handover" is
>>>>tied
>>>>to
>>>>>>   (i) Handover should be fast (this is only true for a direct
>>>>>>pMAG/AR
>>>>>>to
>>>>>> nMAG/AR solution such as
>>>>>>
>>>>>>
>>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult
>>>>>>ic
>>>>>>ast).
>>>>>>
>>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult
>>>>>>ic
>>>>>>ast
>>>>>>(http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mul
>>>>>>ti
>>>>>>cast
>>>>>>http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-mult
>>>>>>ic
>>>>>>ast.
>>>>>>
>>>>Tor
>>>>7 °

---

From: Stig Venaas <[email-masked]>
Date: Tue, 27 Nov 2012 10:53:24 -0800

> The draft title and the draft name should be consistent, and not mislead,

It's a bit misleading, but the name does not matter much. The RFC won't
have the draft name mentioned anywhere.

Can't we rather discuss how the two real fast handover drafts meet
the requirements?

Stig

---

From: "Rajeev Koodli (rkoodli)" <[email-masked]>
Date: Tue, 27 Nov 2012 19:23:05 +0000

Hi Stig,

>have the draft name mentioned anywhere.

IMHO, that's not a reason to be sloppy and misleading.
You didn't say what's the issue with using the appropriate draft name?

>Can't we rather discuss how the two real fast handover drafts meet

I admit I am not on this alias much.

I don't understand what is considered "fast handover" here.
Based on what I have read, it's supposed to be a closed issue, and the WG
is moving on with the WG ID that is called "*-fast-handover-*".
And, I have an issue with this misleading naming suggested/adopted by the
chairs.
Please fix the name.

That's it! :-)

-Rajeev

>>>>>>>> after the - somewhat uninformed discussion at IETF85 - chairs
>>>>>>>>asked
>>>>>>>> me to

---

From: John William Atwood <[email-masked]>
Date: Tue, 27 Nov 2012 14:33:57 -0500

As an aside, while the draft name does not appear in the RFC, it _will_
appear in the datatracker entry for the RFC (once the RFC is published).
 I support Rajeev's suggestion to fix the name of the draft (even though
the draft is already at the -03 level).

  Bill

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8