Subject: [Mobopts] Review of draft-irtf-mobopts-mpa-framework-00

From: Christian Vogt <[email-masked]>
Date: Wed, 24 Oct 2007 17:28:16 +0200

Folks,

Ashutosh asked me to take a look at
draft-irtf-mobopts-mpa-framework-00, which I am happy to do.

Draft-irtf-mobopts-mpa-framework-00 specifies a framework 
for efficient and secure handovers of mobile hosts between 
administrative separate networks.  This includes a 
pre-authentication of the mobile hosts to one or more 
candidate networks.  The framework is generic in that it is 
independent of the authentication mechanism and mobility 
protocol.

A strength of this framework is that it is based on security
relationships between a mobile host and different networks,
whereas it does not depend on trust or security
relationships between administrative separate networks.
This is an advantage in terms of deployment scalability, in
particular in a more and more heterogeneous Internet.

The draft is of good editorial quality.  It also describes
related work and clearly explains how it differs from that.

Below some more specific technical comments:

- One meta-question I have is why the proactive handover
tunnel connects the mobile host's old point of attachment
with the new access router, and not the mobile host's new
point of attachment with the old access router.  In most
cases, this may not make a difference.  But if the signal
strength on the old link is fading quickly, it would be
advantageous to have the mobile host connect to the new
point of attachment as early as possible.  E.g., F-MIPv6
follows the latter approach and may hence work better when
the overlap between the old and new point of attachment is
small.

- Section 1.1 lists end-to-end delay as a performance
requirement and cites ITU-T G.114 (One-Way Transmission
Time).  The transmission time is not directly related to
mobility management, however, unless you consider
propagation stretches that arise from tunneling, such as in
case of the proactive handover tunnel.

- Section 1.1:

> During a mobile's handover, transient traffic cannot
> reach the mobile and this contributes to the jitter as
> well.

Transient traffic during a handover is lost, whereas jitter
considers the deviation in inter-arrival times of
successfully delivered packets.  So the loss of transient 
traffic during a handover does not contribute to jitter.  I 
would rephrase this.

> According to ETSI TR 101 [ETSI], a normal voice 
> conversation can tolerate up to 2% packet loss.

This value is, to my knowledge, the mean packet loss
probability that can be repaired by loss concealment
techniques.  The value hence does not apply to the handover
case, which is special in that the packet loss probability
is 100% for a short period.  Total packet loss cannot be
repaired by loss concealment techniques -- although some
techniques /attempt/ to repair it by repeating the last
received voice frame several times with decreasing volume.

A more appropriate metric than the average packet loss
probability would be the handover delay (i.e., for how long
there is a packet loss of 100%).  The handover delay is the 
time during which the user does not hear anything. 
Unfortunately, ITU has to my knowledge never developed a 
recommendations on what the maximum handover delay should be.

- Figure 1:  Connection between access routers misses in
domain B.  L2 switch in domain B is not labeled.

- Section 6.3:  Maybe you should add some recommendations on 
who eagerly the mobile host should pre-authenticate with 
different candidate networks.  These recommendations should 
optimally consider the mobile host's policies, signaling 
overhead, and handover robustness.

This is a valuable contribution.  Go ahead and publish once 
Rajeev and William give you green light! :-)

Ciao,
- Christian

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

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 24 Oct 2007 11:59:54 -0400

Christian,
           Appreciate your careful review of the draft 
draft-irtf-mobopts-mpa-framework-00. We will take care of these comments 
and suggestions in the revised version of the draft.

Based on Rajeev's email few days back, I also take this opportunity to 
solicit comments and suggestions from others in the mailing list on this 
draft.

Regards
Ashutosh

Christian Vogt wrote:
> Draft-irtf-mobopts-mpa-framework-00 specifies a framework for efficient 
> and secure handovers of mobile hosts between administrative separate 
> networks.  This includes a pre-authentication of the mobile hosts to one 
> or more candidate networks.  The framework is generic in that it is 
> independent of the authentication mechanism and mobility protocol.
> 
> successfully delivered packets.  So the loss of transient traffic during 
> a handover does not contribute to jitter.  I would rephrase this.
> 
>> According to ETSI TR 101 [ETSI], a normal voice conversation can 
>> tolerate up to 2% packet loss.
> 
> there is a packet loss of 100%).  The handover delay is the time during 
> which the user does not hear anything. Unfortunately, ITU has to my 
> knowledge never developed a recommendations on what the maximum handover 
> delay should be.
> 
> - Section 6.3:  Maybe you should add some recommendations on who eagerly 
> the mobile host should pre-authenticate with different candidate 
> networks.  These recommendations should optimally consider the mobile 
> host's policies, signaling overhead, and handover robustness.
> 
> This is a valuable contribution.  Go ahead and publish once Rajeev and 
> William give you green light! :-)
> 
> Ciao,
> - Christian
> 
> 
>

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 24 Oct 2007 19:30:53 -0400

Christian,
           Please see answers to some of the technical questions you 
have asked. We can probably take care of most these comments by 
explaining properly in the revised document, but I am answering some of 
those for the benefit of discussion. Please see inline.

> the overlap between the old and new point of attachment is

There are basically three reasons why the proactive tunnel is set up 
between the new AR and the mobile in the old PoA during proactive 
operation of MPA.

1. Since this draft emphasizes on inter-domain handoff optimization, 
security association between the end-points of the proactive transient 
tunnel is very important. Thus, security association can be ensured by 
having a secured tunnel between new AR (NAR) and the mobile in the old 
PoA, as the pre-authentication with the target network takes place 
before the secured tunnel is established.

2. By having the secured proactive tunnel between NAR and the mobile in 
old PoA, binding update can be sent when the mobile is in the previous 
network. This will avoid the delay due to binding update after the 
handover and effect will be felt the best in cases where CN and MN are 
far part.

3. Since this inter-domain optimization framework is independent of the 
mobility protocol (e.g., MIPv6, SIP, PMIP) one does not need to couple 
it with the specific optimization techniques associated with each of the 
candidate mobility protocols. It can just use the regular binding update 
and re-INVITE that are part of MIPv6 or SIP respectively over this 
secured tunnel.

	On other hand as you have pointed out, there is a tradeoff associated 
here, e.g., it is important to pre-authenticate and set up the tunnel 
ahead of time in case of quickly fading signal or fast-moving vehicle. 
Pre-authentication time can be pre-determined based on mobile's movement 
pattern or signaling fading pattern. Assuming inter-domain handoffs are 
not that frequent or sudden, this problem could be taken care of by 
completing pre-authentication on certain threshold of SNR for example.

> case of the proactive handover tunnel.

Although, tunneling may contribute to the one-way delay, we are talking 
about
the one-way-delay (OWD) for the in-handoff transient packets. It is 
important
to reduce the one-way-transmission delay for the in-handoff packets, and 
that is
where we need to worry about one-way transmission delay. If there is a 
way to

Although tunneling may contribute to the one-way-delay little bit, we 
are focusing on the one-ways-delay (OWD) for the in-handoff packets that 
are in transit. It is important to reduce the one-way transmission delay 
for the in-handoff packets. If we capture the in-handoff packets by 
applying buffering, then impact on one-way-delay for these packets could 
be considered important.

> a handover does not contribute to jitter.  I would rephrase this.

First successful packet after the handoff still has a large 
inter-arrival packet gap compared to the packet that arrived 
successfully before handoff. Additionally, when buffering module is used 
at NAR,  packets in transit are not lost, but these are buffered, and 
their arrival is delayed thus contributing to the jitter for those 
in-handoff packets. One could see a spike for the in-handoff packets, 
when buffer is flushed after the handoff is complete. We have seen these 
both for FMIPv6 and MPA. This could be rephrased as you suggested to 
make it more clear.

> knowledge never developed a recommendations on what the maximum handover 

Agreed, this value is mean packet loss and may not make sense to a 
single handover but may apply to a multiple handovers during a single 
conversation, with each contibuting to some packet loss.

Although there are several techniques such as FEC to reduce the packet 
loss, for handoff scenarios one can reduce the packet loss by using 
buffering techniques at the expense of additional one-way-delay. Thus, 
one can practically reduce the packet loss to zero by adding additional 
buffering delay at the network node, such as NAR. For real-time traffic 
such as VoIP, this does not help  however, if the buffering delay is too 
much.
	A trade-off between buffering delay and packet loss is important and an 
optimal buffering technique is important to support real-time traffic 
during handoff. We have done some experiments in that respect and had 
published some results in a paper in PIMRC 2006 (Helsinki), where we 
used this framework and adjusted the buffer value to obtain a reasonable 
balance between packet loss and one-way-delay (OWD) for the in-handoff 
packets.

> domain B.  L2 switch in domain B is not labeled.

Will take care of the correction.

> host's policies, signaling overhead, and handover robustness.

I think one can use some policy-based decision making for supporting
pre-authentication with multiple candidate networks or deciding which 
one is the preferred target network to pre-authenticate. We can add some 
recommendations on what metrics could be used to optimally decide the 
target network.

Regards
Ashutosh