ietf
[Top] [All Lists]

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

2011-07-29 02:57:07
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.


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>