Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt>

Philip Homburg <pch-ietf@u-1.phicoh.com> Fri, 29 July 2011 07:56 UTC

Return-Path: <pch-b2B3A6689@u-1.phicoh.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0F221F8799; Fri, 29 Jul 2011 00:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.799
X-Spam-Level:
X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
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 ieKG+cBJdQ3r; Fri, 29 Jul 2011 00:56:44 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE4121F87C5; Fri, 29 Jul 2011 00:56:44 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QmhvM-0001gVC; Fri, 29 Jul 2011 09:56:00 +0200
Message-Id: <m1QmhvM-0001gVC@stereo.hq.phicoh.net>
To: Martin Rex <mrex@sap.com>
From: Philip Homburg <pch-ietf@u-1.phicoh.com>
Sender: pch-b2B3A6689@u-1.phicoh.com
In-reply-to: Your message of "Fri, 29 Jul 2011 04:38:12 +0200 (MEST) ." <201107290238.p6T2cCLu021118@fs4113.wdf.sap.corp>
Date: Fri, 29 Jul 2011 09:55:16 +0200
X-Mailman-Approved-At: Fri, 29 Jul 2011 04:16:39 -0700
Cc: hybi@ietf.org, ietf@ietf.org, Mark Andrews <marka@isc.org>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt>
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 07:56:46 -0000

In your letter dated Fri, 29 Jul 2011 04:38:12 +0200 (MEST) you wrote:
>Mark Andrews wrote:
>> Martin Rex writes:
>> > Mark Andrews wrote:
>> > > 
>> > > More correctly it is try the first address and if that doesn't
>> > > connect in a short period (150...250ms) start a second connection
>> > > to the next address while continuing with the first.  If you have
>> > > more that 2 address you do something similar for the next one
>> > 
>> > Happy eyeballs means that a clients reaction to congestion is
>> > to perform an DoS attack, flood the network with additional
>> > connection requests and hammer the server with many additional
>> > half-open connections that will never actually get used.
>> 
>> It is not a DoS attack.  The client is almost certainly going to
>> make those connection attempts anyway if the path is congested
>> enough to cause the first connection attempt to fail.  The only
>> difference is the application gives up in 30 seconds rather than
>> 60 or 90 seconds by doing the attempts serially.
>
>150...250ms  ?!
>
>For a satellite link you already have started 3 parallel connects
>in non-congested(!) situations. 
>
>just some random IPv4 pings from my office (in germany)
>_without_congestion_:
>
>   ping  www.asus.com.tw            300-380ms
>   ping  south-america.pool.ntp.org 280-370ms
>   ping  oceania.pool.ntp.org       340-420ms
>   ping  www.eff.org                160-170ms
>   ping  www.ietf79.cn              330-450ms
>   ping  www.ietf76.jp              270-370ms
>
>So your approach is already hurting the network without congestion!

There are two ways to do Happy Eyeballs. A simple immediate solution that
works in most cases to use a fixed timeout value. In your case, you would
have to increase that value to a bit higher than 400ms. If HE was invented
a long time ago, then by now there could have been a parameter in DHCP
to let the network control this parameter.

The other way of doing HE is make it react to observed connect time. In that
case if you are regularly connecting to sites that are more than 400ms away
then the parameter will automatically increase to that value.

The proposal is currently discussed in v6ops and everybody seems to be happy 
with it. So a critical voice may help shape the proposal a bit.