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

From: Gerardo Giaretta <[email-masked]>
Date: Mon, 13 Jun 2005 11:52:38 +0200

Hi Christian,

thanks for your replay. Some comments below...

> 
> 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-0
> 1-pre.txt
> 
> - Christian
> 
> ++++
> 
> > 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).
> 
> 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?
> 

Yes, it can be an issue. But this depends on the device capabilities and
not on strong application requirements. Usually, in most streaming
applications, buffer size is configurable and has a default value of few
seconds. 

> Anyway, I changed the text.
> 

Good.

> > - 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
> 
> 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.
> 
> > - 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.
> 
> 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.
> 

I tend to agree on this. This implementation choice can improve
performance. 

> > - 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
> 
> Definitely a good idea.
> 
> > - 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"?
> 
> 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?
> 

Not necessarily. However, even without any reference, some more details
can be useful. As you mention RR was designed with low computational
complexity in mind. If you state that it can be too expensive, you
should at least provide some examples, scenarios or data.

--Gerardo

> > - 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".
> 
> 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.
> 
> > Editorial comments:
> > 
> > - section 4.1, last paragraph: Section 6.3.1 should be in 
> brackets or
> >  similar
> 
> 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.
> > 
> > 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 
> > ====================================================================
> 
> 

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
====================================================================

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