[Mobopts] Re: Review of draft-irtf-mobopts-mpa-framework-00
Ashutosh Dutta <adutta@research.telcordia.com> Wed, 24 October 2007 23:32 UTC
Return-path: <mobopts-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkpiH-0000XD-Kj; Wed, 24 Oct 2007 19:32:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkpiG-0000P2-Pc for mobopts@irtf.org; Wed, 24 Oct 2007 19:32:36 -0400
Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikpi7-0000qp-KG for mobopts@irtf.org; Wed, 24 Oct 2007 19:32:33 -0400
Received: from [128.96.58.178] (vpntnlA178.research.telcordia.com [128.96.58.178]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id l9ONUsSh026122; Wed, 24 Oct 2007 19:30:54 -0400 (EDT)
Message-ID: <471FD5AD.7040803@research.telcordia.com>
Date: Wed, 24 Oct 2007 19:30:53 -0400
From: Ashutosh Dutta <adutta@research.telcordia.com>
User-Agent: Thunderbird 1.5.0.13 (Windows/20070809)
MIME-Version: 1.0
To: Christian Vogt <christian.vogt@nomadiclab.com>
References: <471F6490.2010700@nomadiclab.com>
In-Reply-To: <471F6490.2010700@nomadiclab.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48
Cc: ktaniuchi@tari.toshiba.com, William Arbaugh <waa@cs.umd.edu>, Mobopts <mobopts@irtf.org>, vfajardo@tari.toshiba.com, Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: [Mobopts] Re: Review of draft-irtf-mobopts-mpa-framework-00
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Errors-To: mobopts-bounces@irtf.org
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 Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts
- [Mobopts] Review of draft-irtf-mobopts-mpa-framew… Christian Vogt
- [Mobopts] Re: Review of draft-irtf-mobopts-mpa-fr… Ashutosh Dutta
- [Mobopts] Re: Review of draft-irtf-mobopts-mpa-fr… Ashutosh Dutta