IETF Logo Mail Archive

Re: [nbs] NBS assumptions: What can change?(was: Re: NBS and TCP connection identification)

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 05 October 2010 20:27 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7496B3A6FDE for <nbs@core3.amsl.com>; Tue, 5 Oct 2010 13:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.604
X-Spam-Level:
X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5IBPmicbhMq for <nbs@core3.amsl.com>; Tue, 5 Oct 2010 13:27:58 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 48E343A6FB8 for <nbs@ietf.org>; Tue, 5 Oct 2010 13:27:58 -0700 (PDT)
Received: by bwz9 with SMTP id 9so6254977bwz.31 for <nbs@ietf.org>; Tue, 05 Oct 2010 13:28:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YjR5LQQakf/huSsQGMJg0Duuec3cF3ZdWdV9L+pUg+U=; b=Z9FTx9G6wqL1WFUaWI5sjxtZ1VDq6bPLcliXxDynbtPQI57hmp6kV4vM3oOhoMm/0O WIjumuSqUdvA89je811Lg90IkUgJWt7m68hIBowZqxTAHKbbk+XY01j+XPgn7vSC0aoM FvSWYdL5LFmGV76WWrvn5hyoGVeuK+MItNNuk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=NkNU5lEddXY4SZ6eq7tV/cclayZVeHcEWOtAL2FLdNqgOjw+xx/XioRl+J1fUwl5Yh DNvAtaPexhegR51qaguz1qPGj94HIWQsyfZ2nrZ6C6MdmElqIgppgTyhALtEJsfLlR3z 2EjBUsq1VjdVuWJvSTMdC4yHLAoh+h3vvCjKw=
Received: by 10.204.73.1 with SMTP id o1mr6474417bkj.71.1286310535775; Tue, 05 Oct 2010 13:28:55 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id d27sm5320403bku.22.2010.10.05.13.28.48 (version=SSLv3 cipher=RC4-MD5); Tue, 05 Oct 2010 13:28:54 -0700 (PDT)
Message-ID: <4CAB8A78.6090501@gmail.com>
Date: Wed, 06 Oct 2010 09:28:40 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Javier Ubillos <jav@sics.se>
References: <4C97D9A8.2050001@oracle.com> <ACE9611A-9107-46EC-ADD2-56E553DC1C3A@ericsson.com> <4C9826D0.2060703@oracle.com> <1285067950.2068.59.camel@bit> <4C98D525.1030808@oracle.com> <1285148838.2211.60.camel@bit> <4C9A38A1.9060307@oracle.com> <1285251552.2225.109.camel@bit> <4CA60E4B.9050803@oracle.com> <1286278177.2249.347.camel@bit>
In-Reply-To: <1286278177.2249.347.camel@bit>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: nbs@ietf.org
Subject: Re: [nbs] NBS assumptions: What can change?(was: Re: NBS and TCP connection identification)
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Oct 2010 20:27:59 -0000

On 2010-10-06 00:29, Javier Ubillos wrote:

>>  From what I understand from folks at Google a significant part of the 
>> "connection setup" is actually the DNS lookup,

This isn't news. Many years ago, Christian Huitema did a survey of
where the time went in fetching web pages. In 1996, the DNS lookup
was 13% of the total time to load a page, and establishing the actual
connection was only 12%. The full data that he gave:

DNS 13%
Connect 12%
Prepare 33% (i.e. the pause between sending the GET and starting to receive the reply)
Transmit 42%

Data presented at Interop (Paris) in early 1997, but has this really changed?

If we can still learn from this: optimising the lookup/connect phase is
only optimising 25% of the total time as far as the user is concerned.
And half that time is DNS lookup in every possible scenario. Optimising
the connect phase is only optimising 12% of the total time.

    Brian

v2.23.0 | Report a Bug | By Email