RE: [Seamoby] delay data requested

"Gary Kenward"<gkenward@nortelnetworks.com> Wed, 09 January 2002 21:16 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15925 for <seamoby-archive@odin.ietf.org>; Wed, 9 Jan 2002 16:16:16 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19314; Wed, 9 Jan 2002 15:54:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19283 for <seamoby@optimus.ietf.org>; Wed, 9 Jan 2002 15:54:02 -0500 (EST)
Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14929 for <seamoby@ietf.org>; Wed, 9 Jan 2002 15:53:58 -0500 (EST)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g09KrS619262; Wed, 9 Jan 2002 15:53:28 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g09KrQG22979; Wed, 9 Jan 2002 15:53:26 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <CTRGG0KW>; Wed, 9 Jan 2002 15:51:53 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4754@zcard031.ca.nortel.com>
From: Gary Kenward <gkenward@nortelnetworks.com>
To: 'Phillip Neumiller' <PNeumiller@meshnetworks.com>, "'Shahrier, Sharif M.'" <Sharif.Shahrier@interdigital.com>, "'mobileip@sunroof.eng.sun.com'" <mobileip@sunroof.eng.sun.com>
Cc: seamoby@ietf.org
Subject: RE: [Seamoby] delay data requested
Date: Wed, 09 Jan 2002 15:52:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1994F.7EE70520"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org

Phil:

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: January 9, 2002 14:07
> To: 'Shahrier, Sharif M.'; 'mobileip@sunroof.eng.sun.com'
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] delay data requested
> 
> 
> Hi Shahrier,
>  
> This is a very good question.
>  
> 1).  Since CT has to support inter-domain transfers, I would suspect these
would take 
>       longer than intra-domain.  Then again, I am not sure if you are
referring to > > > SeaMoby
>       CT or something else???  The way the CT requirements read there is a
built in
>       dependency on forming  a security association with the newAR before
a CT can
>       take place, so that can also delay things considerably I imagine.
> 
[gwk] There was much discussion around this point. The requirement is only
that the 
association must exist for a ct to be performed. It does not specify when
the association is established. So, you can do it immediately prior to the
ct or  you can do it when you configure the network(s).
> 
> This is good, as it allows for both options.
> 
> 2).  In the best case, your ARs are joined on a fixed network with very
low latency
>       probably << 1 ms I would imagine.
> 
Let's see: a 1G link would introduce about 32 nano secs of transmission
delay. Everything else would be AR implementation dependent.

Gary
 
> I am sure others will have some thoughts on this.  I am not sure if I
understood your
> question though.
 
> Best regards,
 
> Phil

> --
> Mesh Networks, Inc. (www.meshnetworks.com)
> Phillip D. Neumiller, Staff Scientist
> pneumiller@meshnetworks.com PH: 1-407-659-5387 
> -----Original Message-----
> From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@interdigital.com]
> Sent: Wednesday, January 09, 2002 11:36 AM
> To: 'mobileip@sunroof.eng.sun.com'
> Cc: seamoby@ietf.org; Shahrier, Sharif M.
> Subject: RE: [Seamoby] delay data requested
> 

I am trying to do some calculations on the packet transfer delay between a
pair of ARs. I would like to know what is the raw delay (approx.) to
transfer a 32-bit word from the oldAR to the newAR. I expect this
information was used in some way in the calutations of handover protocols.
If someone can help, I would be grateful, if you can send me a direct
e-mail, as well as posting onto the list.
Thanks.
 
-Sharif.
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures.