Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sun, 24 July 2011 23:59 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A2821F86DD for <ietf@ietfa.amsl.com>; Sun, 24 Jul 2011 16:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.074
X-Spam-Level:
X-Spam-Status: No, score=-0.074 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvtjDJdic3Oz for <ietf@ietfa.amsl.com>; Sun, 24 Jul 2011 16:59:36 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 0122D21F86BC for <ietf@ietf.org>; Sun, 24 Jul 2011 16:59:35 -0700 (PDT)
Received: (qmail 76513 invoked from network); 25 Jul 2011 00:19:04 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 25 Jul 2011 00:19:04 -0000
Message-ID: <4E2CB1B1.3080309@necom830.hpcl.titech.ac.jp>
Date: Mon, 25 Jul 2011 08:58:41 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
References: <9031.1311270000.588511@puncture> <CALiegf=pYzybvc7WB2QfPg6FKrhLxgzHuP-DpuuMfZYJV6Z7FQ@mail.gmail.com> <CAP992=FJymFPKcPVWrF-LkcEtNUz=Kt9L_ex+kLtjiGjL1T46w@mail.gmail.com> <4E28A51F.4020704@callenish.com> <9031.1311286867.939466@puncture> <4E28BA9D.6010501@callenish.com> <CAP992=GedTEfimykCWwdwm=BsZdwFRJO36EO0a_o7iejURJ+tQ@mail.gmail.com> <CALiegfnwNyYDy=SyrqHJXV0ZreADb7F8QySvgdHofW9Hm9miZQ@mail.gmail.com> <CABLsOLCgxDNDs54GUybBzmG8a6rNPzXzFcwf_OU25j5L+AobaQ@mail.gmail.com> <CALiegfnp+kNqnU-_x2ZBZnN8fzP=4+6WO=QPjw1rJzvZmSXEAg@mail.gmail.com> <20110724185949.GB22405@1wt.eu>
In-Reply-To: <20110724185949.GB22405@1wt.eu>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jul 2011 23:59:36 -0000

Willy Tarreau wrote:

> On lossy networks such as 3G, they definitely are. A lost UDP packet is
> not retransmitted nor signaled as lost, so the browser has to retry. However,
> once the connection is established to the server, most losses are more or
> less smoothed by TCP extensions such as SACK. So yes, it can take several
> seconds to just resolve a host and then only a few hundreds of ms to retrieve
> the objects. I've observed it.

Poor implementation.

If the network between a mobile phone and its name server is known
to be lossy and latency is the issue, send multiple queries to the
name server.

						Masataka Ohta