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

[Ashutosh Dutta <[e-mail]>]

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.

Christian Vogt wrote:

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

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.

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

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.

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


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.

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

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.

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

Will take care of the correction.

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

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

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

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