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.
- RE: [Seamoby] delay data requested Shahrier, Sharif M.
- RE: [Seamoby] delay data requested Phillip Neumiller
- Re: [Seamoby] delay data requested Vijay Devarapalli
- RE: [Seamoby] delay data requested Gary Kenward