Subject: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 02 Jun 2005 00:20:28 +0200

Hi Christian and Jari,

Raj requested me to review draft-irtf-mobopts-ro-enhancements-00. Here
are some comments and question.

General comment: I think the draft is very well-written and provide a
complete analysis of the topic. The unique general issue I found is that
it is very long. I agree with James' comment that the draft could be
shortened removing some sections that are not completely in the scope of
the draft (e.g. section 5.13 and 5.14, more about these sections below).

More detailed comments:

- section 1, paragraph 4 "In the opposite direction, the mobile node may
tunnel packets to the home agent". I think this sentence is not
completely correct, or at least a bit misleading. If route optimization
is not used, the MN MUST tunnel packets to the HA. Is "MAY" used in this
sentence to highlight that the MN can choose to use bidirectional
tunneling or route optimization? 

- section 1, paragraph 10 "This can lead to handover delay unacceptable
for many real-time or interactive applications like Voice over IP (VoIP)
and audio or video streaming". I'd suggest to remove audio/video
streaming here. Streaming applications are not real-time nor
interactive: they usually buffer few seconds of the movie/sound and thus
are usually not affected by MIPv6 handover latency. At least this is
what we have experimented in our labs.

- section 3.1, paragraph 7 "The mobile node must compute a
message-authentication code keyed with the Home and Care-of Keygen
Token". Actually the MAC is keyed with the Kbm, that is a 20 octets
SHA-1 hash of the concatenation of Home and Care-of Keygen Token

- section 4.1, paragraph 1: I would mention explicitly that the handoff
latency for a route-optimized communication is longer than for a
bi-directional tunneled communication.

- section 4.1, paragraph 2: since the CN is not always required to send
the BA, I wonder why the MN should by default wait for the BA. Or are
you suggesting the MN asks the CN an ack? If so, I think the sentence
should be rephrased.

- section 4.1, paragraph 3 "But more generally, mobile nodes wait for
the home registration to be completed and acknowledged before initiating
the correspondent registration". Are you referring to some specific
implementations? I'm asking this because the open source implementation
we use in our labs does not wait the BA.

- section 4.4, paragraph 2: I would add references to
draft-koodli-mip6-location-privacy-00 and to
draft-koodli-mip6-location-privacy-solutions-00

- section 5.2, paragraph 1:  What do you mean by "close to the mobile
node"? Shouldn't it be "on the path between MN and HA"?

- section 5.3, paragraph 2: the sentence is not clear to me. The last BA
is referred to BA from CN, I suppose. If so, I think it should be
mentioned explicitly.

- section 5.13: as mentioned before I think this section is not really
in the scope of the draft. If you think it is, I'd suggest to include
some more text explaining how HMIPv6 influences RO operations (e.g.
reduction of signaling overhead). The same applies to section 5.14. I
think that FMIPv6 has even less impact on RO than HMIPv6. So I suggest
you include some more text to explain how these protocols are tied to
RO.

- section 5.16, last sentence: are there simulations that prove that RR
can be too expensive? A reference could be helpful. 

- section 6.2.1, last paragraph: HMIPv6 causes always a tunneling
overhead that is not present in plain MIPv6. Therefore, some localized
mobility protocols always cause overhead and not only "in some
situations".

- section 6.2.2, paragraph 1 "On the other hand, nodes that do share a
common secret should be allowed to omit the home-address test". Isn't
required that the common secret is tied to the Home Address used in
order to remove the home address test?

Editorial comments:

- section 4.1, last paragraph: Section 6.3.1 should be in brackets or
similar

- section 5.1, paragraph 2: s/IP-ddress/IP-address

- section 5.7, paragraph 5: s/its is the data/it is the data

- section 5.8, paragraph 2: s/it in general/it is in general

Hope this helps.

Regards,
--Gerardo

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 07 Jun 2005 12:46:48 +0200

In your previous mail you wrote:

=> a general problem in MIPv6 specs is there is no explanation about
when a BA should be asked (always with the HA, and with a CN only when
the previous CoA no more works).

=> as an implementor I agree: there is no reason to wait! And this should
be more true with alternate RO protections.

Regards

[email-masked]

---

From: Christian Vogt <[email-masked]>
Date: Thu, 09 Jun 2005 16:45:45 +0200

Hi Gerardo,

thanks again for reviewing the doc.  Some responses below.  You can 
check the new version at

http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-01-pre.txt

- Christian

++++

>  complete analysis of the topic. The unique general issue I found is
> that it is very long. I agree with James' comment that the draft
> could be shortened removing some sections that are not completely in
> the scope of the draft (e.g. section 5.13 and 5.14, more about these
> sections below).

Ok, will do that.

> More detailed comments:
> 
> - section 1, paragraph 4 "In the opposite direction, the mobile node
> may tunnel packets to the home agent". I think this sentence is not 
> completely correct, or at least a bit misleading. If route
> optimization is not used, the MN MUST tunnel packets to the HA. Is
> "MAY" used in this sentence to highlight that the MN can choose to
> use bidirectional tunneling or route optimization?

You are right, the text is misleading.  The idea was that RO is the
alternative, and the MN may choose (provided the CN supports RO).  But,
again, this is confusing, so I changed it.

> - section 1, paragraph 10 "This can lead to handover delay
> unacceptable for many real-time or interactive applications like
> Voice over IP (VoIP) and audio or video streaming". I'd suggest to
> remove audio/video streaming here. Streaming applications are not
> real-time nor interactive: they usually buffer few seconds of the
> movie/sound and thus are usually not affected by MIPv6 handover
> latency. At least this is what we have experimented in our labs.

Would you say that rapid handovers and small buffers in less-provisioned
devices can be an issue with streaming?

Anyway, I changed the text.

> SHA-1 hash of the concatenation of Home and Care-of Keygen Token

Right, this was imprecise.  Corrected it.

> - section 4.1, paragraph 1: I would mention explicitly that the
> handoff latency for a route-optimized communication is longer than
> for a bi-directional tunneled communication.

Yes, it's added.

> - section 4.1, paragraph 2: since the CN is not always required to
> send the BA, I wonder why the MN should by default wait for the BA.
> Or are you suggesting the MN asks the CN an ack? If so, I think the
> sentence should be rephrased.

Right.

>  the home registration to be completed and acknowledged before
> initiating the correspondent registration". Are you referring to some
> specific implementations? I'm asking this because the open source
> implementation we use in our labs does not wait the BA.

Kame-Shisa does it.  We added the optimization not to wait for the BA
from the HA.

Actually, not waiting for the BA is not standard-conform.  RFC 3775 says
that the lifetime of correspondent registrations must not exceed that of
the home registration.  And the latter becomes known to the MN only with
the BA.

I don't think this requirement is critical, though.  After all, it's up
to the MN to request the CN lifetime anyway.  It could just ignore the
home-registration lifetime.

> draft-koodli-mip6-location-privacy-solutions-00

Definitely a good idea.

>  node"? Shouldn't it be "on the path between MN and HA"?

The critical link on the patch between the MN and the HA is a wireless
first hop.

Anyway, the text is unclear.  Rewrote that sentence.

> - section 5.3, paragraph 2: the sentence is not clear to me. The last
> BA is referred to BA from CN, I suppose. If so, I think it should be 
> mentioned explicitly.

Done.

> - section 5.13: as mentioned before I think this section is not
> really in the scope of the draft. If you think it is, I'd suggest to
> include some more text explaining how HMIPv6 influences RO operations
> (e.g. reduction of signaling overhead). The same applies to section
> 5.14. I think that FMIPv6 has even less impact on RO than HMIPv6. So
> I suggest you include some more text to explain how these protocols
> are tied to RO.

It seems there is pretty much agreement in that FMIPv6 and HMIPv6 should
be removed from this particular document.

> - section 5.16, last sentence: are there simulations that prove that
> RR can be too expensive? A reference could be helpful.

I don't have such a reference.  Is your suggestion to remove the section
in this case?

> overhead that is not present in plain MIPv6. Therefore, some
> localized mobility protocols always cause overhead and not only "in
> some situations".

That's right.  But I have already removed that sub-section.

> - section 6.2.2, paragraph 1 "On the other hand, nodes that do share
> a common secret should be allowed to omit the home-address test".
> Isn't required that the common secret is tied to the Home Address
> used in order to remove the home address test?

You are right.  Added that.

> - section 4.1, last paragraph: Section 6.3.1 should be in brackets or

Oops, it's done.

> - section 5.1, paragraph 2: s/IP-ddress/IP-address

Ok.

> - section 5.7, paragraph 5: s/its is the data/it is the data

Ok.

> - section 5.8, paragraph 2: s/it in general/it is in general

Ok.

> Hope this helps.

It did. ;)

Thanks,
- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

Gerardo Giaretta wrote:
> Hi Christian and Jari,
> 
> Raj requested me to review draft-irtf-mobopts-ro-enhancements-00.
> Here are some comments and question.
> 
>  complete analysis of the topic. The unique general issue I found is
> that it is very long. I agree with James' comment that the draft
> could be shortened removing some sections that are not completely in
> the scope of the draft (e.g. section 5.13 and 5.14, more about these
> sections below).
> 
> More detailed comments:
> 
> - section 1, paragraph 4 "In the opposite direction, the mobile node
> may tunnel packets to the home agent". I think this sentence is not 
> completely correct, or at least a bit misleading. If route
> optimization is not used, the MN MUST tunnel packets to the HA. Is
> "MAY" used in this sentence to highlight that the MN can choose to
> use bidirectional tunneling or route optimization?
> 
> - section 1, paragraph 10 "This can lead to handover delay
> unacceptable for many real-time or interactive applications like
> Voice over IP (VoIP) and audio or video streaming". I'd suggest to
> remove audio/video streaming here. Streaming applications are not
> real-time nor interactive: they usually buffer few seconds of the
> movie/sound and thus are usually not affected by MIPv6 handover
> latency. At least this is what we have experimented in our labs.
> 
> - section 4.1, paragraph 1: I would mention explicitly that the
> handoff latency for a route-optimized communication is longer than
> for a bi-directional tunneled communication.
> 
> - section 4.1, paragraph 2: since the CN is not always required to
> send the BA, I wonder why the MN should by default wait for the BA.
> Or are you suggesting the MN asks the CN an ack? If so, I think the
> sentence should be rephrased.
> 
>  the home registration to be completed and acknowledged before
> initiating the correspondent registration". Are you referring to some
> specific implementations? I'm asking this because the open source
> implementation we use in our labs does not wait the BA.
> 
> - section 5.3, paragraph 2: the sentence is not clear to me. The last
> BA is referred to BA from CN, I suppose. If so, I think it should be 
> mentioned explicitly.
> 
> - section 5.13: as mentioned before I think this section is not
> really in the scope of the draft. If you think it is, I'd suggest to
> include some more text explaining how HMIPv6 influences RO operations
> (e.g. reduction of signaling overhead). The same applies to section
> 5.14. I think that FMIPv6 has even less impact on RO than HMIPv6. So
> I suggest you include some more text to explain how these protocols
> are tied to RO.
> 
> - section 5.16, last sentence: are there simulations that prove that
> RR can be too expensive? A reference could be helpful.
> 
> overhead that is not present in plain MIPv6. Therefore, some
> localized mobility protocols always cause overhead and not only "in
> some situations".
> 
> - section 6.2.2, paragraph 1 "On the other hand, nodes that do share
> a common secret should be allowed to omit the home-address test".
> Isn't required that the common secret is tied to the Home Address
> used in order to remove the home address test?
> 
> 
> Editorial comments:
> 
> Regards, --Gerardo
> CONFIDENTIALITY NOTICE This message and its attachments are addressed
> solely to the persons above and may contain confidential information.
> If you have received the message in error, be informed that any use
> of the content hereof is prohibited. Please return it immediately to
> the sender and delete the message. Should you have any questions,
> please send an e_mail to [email-masked]. Thank you

---

From: Christian Vogt <[email-masked]>
Date: Thu, 09 Jun 2005 18:28:21 +0200

> the previous CoA no more works).

Hi Francis,

you are saying that the MN should request a BA from the CN when the 
previous CoA doesn't work any more.  Is this specified in RFC 3775 as such?

Whether or not it's in RFC 3775, what you say makes sense IMO.

I don't think RFC 3775 mention this, however.  There is just the last 
paragraph on page 133...

Regards,
- Christian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 10 Jun 2005 01:14:21 +0200

=> no but it should be even it is common sense.

=> good implementations (argh, I'll loose some friends :-) should not
blindy put and not put the BA ask flag...

=> it explains what is the effect for the flag, not really when it should
be set to one.

Regards

PS: I mentioned this because IMHO it is one of the killing details which
is (was now :-) nowhere.