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

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Jul 2011 16:31:43 +0200

Hi,

this document has an informative reference to an unstable document at 
<http://dev.w3.org/html5/websockets/>. It should be replaced by a 
reference to the actual W3C WG's Working Draft: 
<http://www.w3.org/TR/websockets/> (and potentially marked "work in 
progress").

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 12 Jul 2011 07:40:52 +0300

Hello,

I'd like to comment the draft-ietf-hybi-thewebsocketprotocol-10, which 
is currently in IETF Last Call.

Throughout the document:

>     _This section is non-normative._

are quite unusual.  Such statements occur at the beginning of 
Introduction, which is meant to be nob-normative a priori, its 
subsections, and Section 4.7, Examples.  These sections, IMO, doesn't 
need to be additionally marked as non-normative.

Section 2.1 makes use of a bit unusual notation; explicitly, it often 
excludes possibility to reference ABNF productions in angle brackets in 
the text.  I don't object to the existing notation (but see below), but 
ABNF rules should be referenced in other way.

Section 3.  I propose to rewrite the first paragraph as follows:

>     This specification defines two URI schemes for WebSocket protocol -
>     'ws' and 'wss'.  Their syntax is defined below using ABNF [RFC5234]
>     in the<ws-uri>  and<wss-uri>, respectively:
>
>       ws-uri  = "ws:" "//" host [ ":" port ] path-abempty [ "?" query ]
>       wss-uri = "wss:" "//" host [ ":" port ] path-abempty [ "?" query ]
>
>     where the<host>,<port>,<path-abempty>  and<query>  rules are
>     defined in RFC 3986 [RFC3986].

Rationale: (1) The first paragraph gets clearer. (2) ABNF is changed not 
ot use pros-vals (RFC 5234) (3) s/path/path-abempty/ to directly import 
it from RFC 3986 (4) Several editorial issues fixed.

I see a number of times the term "WebSocket URI" is used in the draft.  
I would be useful to clarify that the "WebSocket URI" is either a valid 
'ws' or 'wss' URI.

Section 4.2.  I have a concern with usage of ABNF here.  Let's see:

>     frame-fin               = %x0 ; more frames of this message follow
>                             / %x1 ; final frame of this message

Looking at RFC 5234, Section 2.3 we find:

>     Rules resolve into a string of terminal values, sometimes called
>     characters.

Which means that ABNF represents characters only; no bits may be 
represented by it.  Creating the normative and formal definition of a 
header is just impossible.  The above rule will be correctly interpreted as:

>     frame-fin               =<ASCII NUL character 0x00>
>                             /<ASCII SOH character 0x01>

which isn't what you mean.  Changing "x" to "d" to represent binary 
values won't help, since all other bits will be considered to be zeros 
and the result will be the same.  Conclusion: there is no other way 
other that to remove the ABNF definition of WS message here.

Sections 4.5.2. and 4.5.3.  I think the names "ping" and "pong" can 
better be replaced with "echo request" and "echo response".

Section 5.2.2, bullet 3, sub-bullet 4.  When defining the ABNF for a 
header, the header name should be included in it as well.  So the first 
line should be:

> sec-websocket-accept-header = "Sec-WebSocket-Accept:" base64-value

This will also deal with the issue regarding the name of ABNF production 
for the header.

Section 9.1:

>           extension-token = registered-token / private-use-token

If you want RFC 2616 ABNF, this should be changed to:

>           extension-token = registered-token | private-use-token

Ibid:

>           Sec-WebSocket-Extensions: bar; baz=2
>
>     is exactly equivalent to
>
>           Sec-WebSocket-Extensions: foo, bar; baz=2

These two examples don't match the aforementioned ABNF; the space before 
"baz=2" should be removed.

Section 11.1:

> 11.1.  Registration of "ws:" Scheme

The ":" colon isn't included in the scheme name.  So replacing "ws:" 
with 'ws' should be OK.

>     A |ws:| URI identifies a WebSocket server and resource name.

In Section 2.1 you mentioned that |foo| is used when "foo" is a header.  
Please use simple quotes.

>        In ABNF terms using the terminals from the URI specifications:
>        [RFC5234] [RFC3986]
>
>             "ws" ":" hier-part [ "?" query ]

This isn't what you described in Section 3. <hier-part> includes the 
<userinfo> part, which shouldn't be present in WebSocket URIs.  This 
ABNF should be fixed to match one in Section 3.

>        The<path>  [RFC3986] and<query>  components form the resource name
>        sent to the server to identify the kind of service desired.  Other
>        components have the meanings described in RFC3986.

If you adopt my proposal to Section 3, this should be fixed in the same way.

>     References.
>        RFC XXXX

References here mean (from RFC 4395):

>     References.
>        Include full citations for all referenced documents.  Registration
>        templates for provisional registration may be included in an
>        Internet Draft; when the documents expire or are approved for
>        publication as an RFC, the registration will be updated.

So this field should refer to Section 14 of the draft.

Section 11.2: the same applies.

Section 11.12:

>        Version Number  | Reference
>      -+----------------+-----------------------------------------+-
>       | 0              + draft-ietf-hybi-thewebsocketprotocol-00 |
>      -+----------------+-----------------------------------------+-
>         [ . . . ]
>      -+----------------+-----------------------------------------+-
>       | 9              + draft-ietf-hybi-thewebsocketprotocol-09 |
>      -+----------------+-----------------------------------------+-

This looks very strange, since all revisions of the draft will become a 
single RFC.  I propose:

>        Version Number  | Reference
>      -+----------------+-----------------------------------------+-
>       | 1              + This document                           |
>      -+----------------+-----------------------------------------+-

Moreover, what is the allowed range of version numbers (and all other 
values for which the registries are created)?  What entries are 
Unassigned and what are Reserved (I suppose 0 might be Reserved, others 
- Unassigned).

I find the only 2 definitions of syntax of header field described in 
your document - Sec-WebSocket-Accept and Sec-WebSocket-Extensions.  
Where are the other syntax definitions for those header fields 
registered in Section 11?

References.  RFC 3490 is a downward reference here; RFC 3967 procedure 
should have been used.  All other of them seem OK.

I hope my comments were useful.

Thanks,
Mykyta Yevstifeyev

11.07.2011 17:02, The IESG wrote:
> The IESG has received a request from the BiDirectional or
> Server-Initiated HTTP WG (hybi) to consider the following document:
> - 'The WebSocket protocol'
>    <draft-ietf-hybi-thewebsocketprotocol-10.txt>  as a Proposed Standard

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Jul 2011 08:56:38 +0200

On 2011-07-11 16:02, The IESG wrote:
> ..

I believe Section 11 (IANA Considerations) should be grouped to into URI 
scheme registrations, HTTP header field registrations, and new registries.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Jul 2011 08:59:34 +0200

On 2011-07-12 06:40, Mykyta Yevstifeyev wrote:
> ...
> ...

+1

> it from RFC 3986 (4) Several editorial issues fixed.

-10

Granted, it doesn't use prose values anymore, but then it get's 
incomplete. I believe putting references to ABNF productions from other 
specs into prose values is absolutely the right thing to do (as opposed 
to just mention them in prose).

> ...

Why?

> ...

yes.

 > ...

They do, as the RFC 2616 ABNF allows implied Linear Whitespace.

That being said, it might be a good idea to revisit the choice of 
syntax, or at least to clarify the LWS situation.

> <userinfo> part, which shouldn't be present in WebSocket URIs. This ABNF
> should be fixed to match one in Section 3.

...or removed. Why are there two?

> So this field should refer to Section 14 of the draft.

"Section 14 of this document".

> ...

This is indeed fishy and I would be really surprised if IESG and RFC 
Editor let this pass.

If 0..9 can't be reassigned then let's just state they are reserved.

> ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Jul 2011 10:12:35 +0200

On 2011-07-12 09:48, Iñaki Baz Castillo wrote:
> 2011/7/12 Mykyta Yevstifeyev<[email-masked]>:
> Hi, are you sure of that? In SIP protocol (which inherits from HTTP
> grammar) a header parameter (;foo=lalala) can contain spaces anywhere
> (before/after the ";", before/after the "="). So something like:
>
>     Sec-WebSocket-Extensions: foo  , bar  ; baz = 2
>
> is valid.
>
> However it's not clear for me wheter in this example "baz=2" is a
> header param or a param just for the value "bar". In the last case it
> would mean a specific header syntax, so spaces could be not allowed.
> Could you please point to the ABNF grammar you meant?

According to 
<http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-9.1> 
it's a parameter of "bar".

That being said, I'm not happy with

          extension-param = token [ "=" token ]

In HTTP header fields, parameters usually support both token and 
quoted-string form.

Making this special means that existing header field parser code can't 
be easily re-used.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Jul 2011 10:51:43 +0200

On 2011-07-12 10:23, Iñaki Baz Castillo wrote:
> 2011/7/12 Julian Reschke<[email-masked]>:
> Right.
>> Making this special means that existing header field parser code can't be
>> easily re-used.
>
> Well, not exaclty as any parser supporting tokens and quoted-strings
> would also parse "just" tokens :)

But if they *are* re-used, those recipients will accept quoted-strings 
as well (thus accepting invalid header fields). This could be harmless, 
or it could cause them to be used in practice, forcing other recipients 
to accept them as well.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 12 Jul 2011 11:59:56 +0300

12.07.2011 9:56, Julian Reschke wrote:
> I believe Section 11 (IANA Considerations) should be grouped to into 
> URI scheme registrations, HTTP header field registrations, and new 
> registries.
This is quite reasonable. +1.

Mykyta
>
> Best regards, Julian
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 12 Jul 2011 12:09:55 +0300

12.07.2011 9:59, Julian Reschke wrote:
> incomplete. I believe putting references to ABNF productions from 
> other specs into prose values is absolutely the right thing to do (as 
> opposed to just mention them in prose).
I don't have any string position in the way of importing the productions 
from other documents.  However, what is above is what I like more.  
However, what we can see, eg. in 
http://tools.ietf.org/html/rfc5538#appendix-A can be fine as well.
There is the following formulation:

> The 'Foo' headers takes the form of <foo-header> ABNF rules below:
>
> foo-header = *(APHA/DIGIT)

will result in the message headers like:

>          Upgrade: TLS/1.2
>          Connection: Upgrade
>          gfr134

and "gfr134" will be the 'Foo' header.  "foo-header = "Foo:" 
*(APHA/DIGIT)" will result in valid:

>          Upgrade: TLS/1.2
>          Connection: Upgrade
>          Foo: gfr134

See also eg. RFC 3282, RFC 2616.

> syntax, or at least to clarify the LWS situation.
The document may reference the httpbis-p1 where the <n>#<m>rule 
extension will be described for valid ABNF.  See 
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-15#section-1.2.1
> If 0..9 can't be reassigned then let's just state they are reserved.
I believe there is no problems to make the 0..9 spare, except 1, for 
this version of WS.

Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Jul 2011 11:14:54 +0200

>> foo-header = *(APHA/DIGIT)

It should say: "The 'Foo' header field's value takes the form..."

> See also eg. RFC 3282, RFC 2616.

Have a look at the HTTPbis drafts.

> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-15#section-1.2.1

It could, but my guess is that HyBi doesn't want to wait for HTTPbis.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 12 Jul 2011 12:16:43 +0300

>     Sec-WebSocket-Extensions: foo  , bar  ; baz = 2
No, its' everything OK with this issue.  LWS is allowed between 
<extension> productions in the header, but not between the parts of this 
productions: <extension-token>s and <extension-param>s.  See 
http://tools.ietf.org/html/rfc2616#section-2.1 and 
http://tools.ietf.org/html/rfc2616#section-2.1.

> Could you please point to the ABNF grammar you meant?
This was meant to be the parameter for the "bar", as far as I understand.

Mykyta
> Thanks.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 12 Jul 2011 12:21:31 +0300

This will eliminate the problem.  Currently we have:

> The ABNF of this header is defined as follows:

not its entity.
> Have a look at the HTTPbis drafts.
They should also be clear about whether they mean the header field or 
the header field's entity.
> It could, but my guess is that HyBi doesn't want to wait for HTTPbis.
That's up to them.

Mykyta

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 12 Jul 2011 09:48:49 +0200

is valid.

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 12 Jul 2011 10:23:07 +0200

Right.

Well, not exaclty as any parser supporting tokens and quoted-strings
would also parse "just" tokens :)
However I agree that making new/custom grammar for a simple header
makes no sense.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Francis Brosnan Blazquez <[email-masked]>
Date: Tue, 12 Jul 2011 16:13:56 +0200

Hi,

Recently, I posted [1] that websocket protocol should include an
indication about max frame size that is willing to accept the connecting
peer. 

Many pointed this is not an issue because you could use a stream
oriented API (like TCP send/recv and others), but that only bypasses the
problem (in some cases) not solves it.

Websocket protocol is frame based and every frame based protocol
designed until now has/need such feature or similar. Even TCP, for those
that proposes to use a stream oriented API as a solution, includes a
more complex mechanism than a simple max frame size (window based ack),
so each party can control/inform the sender. This is critical.

A good example for this would be the next. Let suppose you have a
constrained memory device (either because it is small or because it
accepts a large amount of connections). On that device you deploy a
websocket app that only accepts small messages (< 512 bytes, let's
say). 

In this context, you can hard code at your web app (javascript) that
must not send messages larger than this size (so you control websocket
payload size) and in the case you need to, you must split them
properly. 

However, even with this mechanism, you have no warranty that the browser
or an intermediary will join those messages into a single frame, causing
your device to receive a bigger message/frame than expected.

Assuming this I think we would require either to include a
Max-Frame-Size indication (or a really poor solution: to explicitly
state on the draft that frames must not be coalesced by intermediaries
or browsers). 

Regards,

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg07641.html
-- 
Francis Brosnan Blázquez <[email-masked]>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL

Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 13 Jul 2011 12:53:52 +1000

Francis et al,

not also that the protocol does support fragmentation and a 1004 frame
too large error.
Even the 1004 error does not carry an indication of what an acceptable
size is, so the client/tool/intermediary that receives a 1004 will
either have to fail or guess a smaller frames size - potentially
binary chopping down to find an acceptable size, which might be sub
optimal.

I simple optional header in the handshake declaring the max frame size
(which intermediaries could adjust) would be very complimentary to the
existing fragmentation and 1004 features and I can't think of any
significant down side.

regards

On 13 July 2011 00:13, Francis Brosnan Blazquez <[email-masked]> wrote:
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: "Len Holgate" <[email-masked]>
Date: Wed, 13 Jul 2011 09:21:57 +0100

Francis,

I agree with your points and would welcome a max frame size negotiation
header.

However, whilst an intermediary might legitimately change the fragmentation
of a frame it cannot merge complete messages. If, in your example, your
client limited itself to messages of a certain size then it doesn't matter
what intermediaries do to the frames as the maximum frame size would be
limited to the maximum message size that the client sends. The only time
this wouldn't work is if you were using a 'message of infinite fragments'
where you start with a fragmented frame and don't know when you'll send the
final fragment.

The communication between peers about maximum message sizes supported could
just as easily be in the application level protocol that you're running over
the websocket connection.

Len
www.lenholgate.com

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Francis Brosnan Blazquez
> Sent: 12 July 2011 15:14
> To: Hybi
> Cc: [email-masked]; [email-masked]
> Subject: Re: [hybi] Last Call: 
> <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket 
> protocol) to Proposed Standard: request for max frame size
> 
> Hi,
>

---

From: "Len Holgate" <[email-masked]>
Date: Wed, 13 Jul 2011 09:22:27 +0100

I agree that this would be very useful. 

Would this be one frame size for both directions, or could it be specified
in each direction? 

I'm a little wary of intermediaries being allowed to adjust this unless
they're only allowed to reduce the amount...

Len
www.lenholgate.com

> Behalf Of Greg Wilkins
> Sent: 13 July 2011 03:54
> To: Francis Brosnan Blazquez
> Cc: Hybi; [email-masked]; 
> [email-masked]

---

From: Francis Brosnan Blazquez <[email-masked]>
Date: Wed, 13 Jul 2011 13:39:11 +0200

Hi Len,

> Would this be one frame size for both directions, or could it be specified

It should be done in both directions, assuming each party may have
different requirements..

> they're only allowed to reduce the amount...

My impression is that this max frame size value would help
intermediaries, and peers, to know how to fragment or coalesce
application level messages. Without such indication they are blind...

---

From: "Len Holgate" <[email-masked]>
Date: Wed, 13 Jul 2011 13:13:09 +0100

> It should be done in both directions, assuming each party may have

That was my feeling on it.

> application level messages. Without such indication they are blind...

I agree.

Len
www.lenholgate.com

---

From: Francis Brosnan Blazquez <[email-masked]>
Date: Wed, 13 Jul 2011 16:27:32 +0200

Hi Len,

> I agree with your points and would welcome a max frame size negotiation

Ok, It shouldn't be a negotiation but an indication to accommodate
communication to each party.

> client limited itself to messages of a certain size

Ok, it is important to note the peer is limiting max frame size not the
message size which may be still infinite in practical terms (63
bits)....and we have fragmentation support to deal with this.

This way intermediaries can split/coalesce fragments according to
receiving peer expectation.

>  then it doesn't matter

Assuming frame size and message size aren't equal, it does matter. 

> the websocket connection.

Ok, I see you point and in part you are right, but there is a risk with
this argument:

1) Protocol problems should be solved on its layer, otherwise it will
   cause next layer (application level in this case) to need to solve
   them. It looks reasonable not forcing people to do so.

     Side note: our intention is to layer BEEP on top of websocket, so,
     in practical terms this is not a problem for us because it will
     provide us with all the protection and flow control required.

     However it looks to me this is not a solution for people using
     websocket in other contexts.

2) In general, it has lot of benefits to fragment bigger messages into
   smaller pieces to avoid sick interactions. 

   For example, if you send a really large frame, you won't be able to
   send a control message in the middle until you finish sending the
   frame in place. 

   Having a max frame size indication will help websocket stacks to
   fragment using the right value for each application.

3) No matter API style provided by a websocket stack (frame indication
or stream oriented), having framing running in the background where the
sending peer and intermediaries can coalesce frames without any
indication of the upper level will cause problems that can't be solved
in practical terms by a receiving side. 

In other words, I think having a framing without a max frame size
mechanism (or other mech like ack confirmation, its the same) is like
pretending having a coin with only one side.

AVISO LEGAL

---

From: "Len Holgate" <[email-masked]>
Date: Wed, 13 Jul 2011 19:35:53 -0000

Francis,

> communication to each party.

Fair point.

> bits)....and we have fragmentation support to deal with this.

I understand. I was just pointing out that in your example, if the client
instead decided to limit the size of messages that it sent then then nothing
could cause any frames to be larger than that limit when they arrived at the
server.

>    them. It looks reasonable not forcing people to do so.

Agree.

>    smaller pieces to avoid sick interactions. 

Agree.

> in practical terms by a receiving side. 

Agree.

Len
www.lenholgate.com

---

From: Julian Reschke <[email-masked]>
Date: Sun, 17 Jul 2011 12:46:38 +0200

This is a set of comments on how the specification defines new HTTP 
header fields and the upgrade token.

1) In the IANA considerations section, please group subsections by 
registrations and new registries.

2) "Specification document(s)" should actually point to the part of the 
spec that *specifies* the thing being registered. Just saying RFC nnnn 
or "this document" wastes the reader's time.

3) That being said, the header field registrations each contain a 
paragraph of prose explaining the header field. *Is* this the 
specification of the header, or does it only summarize more information 
from somewhere else? If so, from where?

4) Each header field definition needs to say what the header means in 
general, and what the syntax is (the latter can be either prose or ABNF, 
but ABNF would be preferred). It's not sufficient to describe it as part 
of a Websocket-specific algorithm - what's needed is a statement about 
what the header means on an HTTP message in general (and yes, saying 
it's only allowed in this or that context, and that it's meaningless 
otherwise would be ok).

Best regards, Julian

---

From: Dave Cridland <[email-masked]>
Date: Tue, 19 Jul 2011 14:26:41 +0100

On Tue Jul 19 12:51:16 2011, Iñaki Baz Castillo wrote:
> 2011/7/11 The IESG <[email-masked]>:
> Hi, I assume there is no interest in making DNS SRV mechanism  
> exposed
> in http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02 part of
> the WebSocket core specification, neither referencing it (in the  
> same
> way RFC 3261 "SIP protocol" mandates the usage of RFC 3263 "Locating
> SIP servers").
> 
> As said before, making such DNS SRV specification an extension (so
> present in other document) will mean no success at all, as WebSocket
> client implementors (i.e. webbrowser vendors) will not be mandated  
> to
> implement it and service providers could not rely on the support of
> DNS SRV in web browsers. So nobody will use them (because IE10  
> decided
> not to implement it, for example). IMHO this is sad due the real
> advantages DNS SRV provides for a protocol like WebSocket.
> 
> Yes, in HTTP there is no special DNS stuff, all the load-balancing  
> and
> failover mechanism are done at server side with very complex and
> expensive solutions (www.facebook.com resolves to a single IPv4  
> !!!!).
> The question is: should we also inherit every HTTP limitation in
> WebSocket?

I agree wholeheartedly with this, and strongly recommend that  
mandatory use of SRV is included in the core protocol.

I think with HTTP's very short lived requests, then it's possible to  
work around the lack of SRV support (at a cost), but the benefit is  
markedly higher with the long-lived, stateful sessions we're  
anticipating with WebSocket.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 19 Jul 2011 13:51:16 +0200

>  <draft-ietf-hybi-thewebsocketprotocol-10.txt> as a Proposed Standard

Hi, I assume there is no interest in making DNS SRV mechanism exposed
in http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02 part of
the WebSocket core specification, neither referencing it (in the same
way RFC 3261 "SIP protocol" mandates the usage of RFC 3263 "Locating
SIP servers").

As said before, making such DNS SRV specification an extension (so
present in other document) will mean no success at all, as WebSocket
client implementors (i.e. webbrowser vendors) will not be mandated to
implement it and service providers could not rely on the support of
DNS SRV in web browsers. So nobody will use them (because IE10 decided
not to implement it, for example). IMHO this is sad due the real
advantages DNS SRV provides for a protocol like WebSocket.

Yes, in HTTP there is no special DNS stuff, all the load-balancing and
failover mechanism are done at server side with very complex and
expensive solutions (www.facebook.com resolves to a single IPv4 !!!!).
The question is: should we also inherit every HTTP limitation in
WebSocket?

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Francis Brosnan Blazquez <[email-masked]>
Date: Tue, 19 Jul 2011 14:51:32 +0200

+1

It is little the effort for web browser implementors and will provide
lot of benefits to end users and developers which would be able to
provide scalable/configurable services easily. I'm with Iñaki: its usage
must be mandatory to really make it available in all browsers...

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 21 Jul 2011 06:28:41 +0300

I support the opinion that SRV mechanism for use with WebSocket should 
be incorporated in the core WS specification.  Mykyta

---

From: Dave Cridland <[email-masked]>
Date: Thu, 21 Jul 2011 17:38:49 +0100

On Thu Jul 21 17:06:59 2011, David Endicott wrote:
> DNS resolution is not a function of a transport protocol. 

I entirely agree, but the specification already includes DNS  
resolution as part of URI resolution and URI scheme definition, and  
as such, if you want all these things - which are, I concur, not a  
function of a transport protocol - removed from this specification,  
then we'll need a distinct document which adds them back in, as it  
were.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 21 Jul 2011 18:40:00 +0100

On Thu Jul 21 18:18:31 2011, David Endicott wrote:
> It is my opinion that name resolution (however done) is outside the  
> purview
> of WS.   It may be handled in any number of ways by the client, and  
> must
> happen *before* WS establishes it's TCP connection and begins  
> handshaking.

The URI scheme is defined here, and absolutely must explain whether  
it's a host (for direct address lookup), or a domain (for SRV).

It's proven impossible, despite effort, to retrofit SRV onto HTTP;  
there is no way it'll be possible to retrofit onto WS.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 21 Jul 2011 21:19:06 +0100

On Thu Jul 21 19:43:07 2011, David Endicott wrote:
> I do not know SIP or XMPP well enough to comment on why they  
> mandated the
> name resolution mechanisms they did.    However, XMPP is used in a  
> highly
> dynamic host environment, so having flexible & extensible name  
> resolution is
> likely an excellent choice.
> 
> 
I have no idea what you might mean by "highly dynamic host  
environment" in this context, but XMPP servers are normally found at  
the same location consistently. However, it is *not* always (or  
typically) the same location as a simple A record lookup:

;; ANSWER SECTION:
_xmpp-server._tcp.isode.com. 259200 IN	SRV	5 0 5269 xmpp.isode.com.

;; ADDITIONAL SECTION:
xmpp.isode.com.		225364	IN	A	62.3.217.250

;; ANSWER SECTION:
isode.com.		73130	IN	A	87.106.143.99

This property alone is very useful - in a websockets case this would  
mean being able to provide websockets services from a different host  
(or network) to the traditional web services in a simple manner,  
fully compatible with SOP.

The fact that this also allows cheap lightweight load balancing and  
fallback control is also useful in other cases; none of this relates  
to dynamic hosts, but simply richer service location.

> I do not oppose DNS's MX records for SMTP as email addresses are  
> name@domain,
> so obviously the Domain Name System is appropriate.    Also, I fail  
> to see
> why a mail admin should care how the SMTP clients arrive at the  
> server.  DNS
> MX is a reasonable solution, but there may be other methods, any  
> and all of
> which are irrelevant to the SMTP server.    Especially when the  
> SMTP server
> supports multiple email domains....
> 
> 
A mail admin does need to care *that* the service is located, and  
therefore will care *how* it is located.

You can be as theoretical as you like, by all means, but in practical  
terms, your email address (and my XMPP address) work because they use  
a defined, interoperable, service location mechanism, which operates  
via DNS record lookup.

(Also, I have no idea what multiple domains has to do with this.)

> Since WS is intended as a browser supported protocol, WS should  
> follow the
> same URI resolution mechanisms as HTTP (or how URI resolution is  
> done in
> general)  Having URLs that could resolve differently for a HTTP  
> request and
> a WS setup is a problem.
> 
> 
But they do resolve differently anyway. You don't get a page from a  
'ws' scheme URI, you get a transport protocol connection. This is  
good, indeed, it's kind of the point.

Your suggestion of "how URI resolution is done in general" is  
somewhat self-defeating, too, since aside from 'http' and 'https',  
there are 'mailto', which uses MX, 'sip' and 'xmpp', which both use  
SRV.

I think opponents of SRV records need to mount a stronger argument  
than the kind of luddite argument that if it's hard for one protocol  
in use by the browser, it should be hard for them all.

Dave.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 20 Jul 2011 23:12:52 +0200

2011/7/19 Dave Cridland <[email-masked]>:
> I agree wholeheartedly with this, and strongly recommend that mandatory use
> of SRV is included in the core protocol.
>
> I think with HTTP's very short lived requests, then it's possible to work
> around the lack of SRV support (at a cost), but the benefit is markedly
> higher with the long-lived, stateful sessions we're anticipating with
> WebSocket.

Unfortunaltely it seems that the debate about DNS SRV support does not
interest to the core WG authors. I would like, at least, to receive
good arguments not to include/mandate DNS SRV support in the draft. If
not, the proposal is just being ignored with no reason.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: David Endicott <[email-masked]>
Date: Thu, 21 Jul 2011 12:06:59 -0400

I am opposed to inclusion in core specification.  I would accept it as
optional extension.

DNS resolution is not a function of a transport protocol.  DNS SRV has no
special association with WS.    It is my opinion that this would be
additional cruft that is only marginally related to the purpose and function
of websockets.    It does not address a general use case.   DNS SRV applies
only to a (small?) subset of server-side implementations.    It is a good
and useful mechanism, but I do not believe it should be tied tightly to
websockets, nor included as part of the core spec.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 21 Jul 2011 18:27:49 +0200

> websockets, nor included as part of the core spec.

An WebSocket URI is given to a WebSocket client, and the client MUST
locate the corresponding WS server, right? and for locating the server
the client MUST follows a procedures which, for now, involve (if it's
not an IP) DNS A/AAAA resolution, right? So now imagine that the
location mechanism is a bit more powerful and also involves SRV
queries (not always).

If you think that a transport protocol (like WebSocket) must not
resolve a server destination then also remove the WS URI inspection
and resolution from the core spec, don't you agree? or just DNS A/AAA
is valid?

I don't agree with your opinion at all. Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 21 Jul 2011 18:39:10 +0200

> I don't agree with your opinion at all. Regards.

Iñaki,

I understand the point David is making. DNS is something independant of
WS and conversely. It is one way of resolving addresses, just like there
will be people using hosts files. At no place the protocol specification
dictates how a client should resolve a name to an IP address. The protocol
specifies the transport part only.

This is the same for other protocols. For instance, neither FTP nor HTTP
explain how a client is supposed to resolve a host name, still the later
explains how to parse a URI. DNS SRV is a DNS extension which only concerns
resolvers. Not all clients will be using resolvers, just a part of them.
Some others will simply forward the request to their HTTP proxy which will
apply whatever DNS resolving method they know, including possibly DNS SRV.

In practice, if there are new elements of DNS SRV that are specific to WS,
they should probably be added to the DNS SRV spec and not the WS spec.
Maybe the WS spec should mention that it addresses transport only and
not address resolving. It may recommend to follow some principles to
perform the resolving but should not specify how to do it.

Hoping it's a bit clearer,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 21 Jul 2011 19:15:13 +0200

> specifies the transport part only.

Host files just replace A/AAAA resolution. Still is possible to query
SRV records and later perform hostfiles check for retrieved hostnames
(instead of performing DNS A/AAAA for them).

> explains how to parse a URI.

Maybe because DNS SRV born later than FTP or HTTP. But now look at SIP
and XMPP protocols which make *extensive* usage of DNS SRV. And SIP is
just a "signaling protocol", you could also consider it a "transport
protocol" which transports sessions and other kind of data. It's at
the very same level than WS, IMHO.

> DNS SRV is a DNS extension which only concerns

If WS spec does not mandate DNS SRV resolution in WS clients (so
webbrowsers mainly) then let's forget SRV balancing/failover
capabilities. If the WS core draft does not want to handle this topic,
then refer to another document mandating it (in the same way SIP RFC
3261 mandates the usage of DNS NAPTR/SRV in RFC 3263 for SIP clients).

So you can split WS in:
- transport specification RFC (handshake, frames and so).
- location WS servers (a MUST for WS clients when resolving WS URI's).

> they should probably be added to the DNS SRV spec and not the WS spec.

No. DNS SRV spec (RFC 2782) just explains the DNS SRV mechanism. Any
protocol can decide wheter to include/mandate it or not. Each protocol
can register in IANA new "service" values SRV, in the same way SIP and
XMPP RFC's create "sip" and "xmpp-server" values.

> perform the resolving but should not specify how to do it.

That would be great, so another document/spec would *mandate* how WS
clients MUST resolve WS destinations. But that is not true now as WS
core spec states simple A/AAAA resolution for locating a WS server.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: David Endicott <[email-masked]>
Date: Thu, 21 Jul 2011 13:18:31 -0400

Thanks Willy, you made my point better than I did.

It is my opinion that name resolution (however done) is outside the purview
of WS.   It may be handled in any number of ways by the client, and must
happen *before* WS establishes it's TCP connection and begins handshaking.

DNS, DNS SRV, etc. are good and useful tools, but are not part of WS.

A document showing how to use DNS SRV with WS would be useful, but it's not
part of the core WS spec.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 21 Jul 2011 19:23:27 +0200

> part of the core WS spec.

Ok, there you have a proposal:

  http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02

:)

Of course, the core WS spec should reference and *mandate* it, or
maybe not and instead a W3C specification should mandate it for
webbrowsers.
And in this case, the WS URI resolution section in core WS spec (DNS A
stuff) should be entirely removed.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 21 Jul 2011 19:33:38 +0200

> - location WS servers (a MUST for WS clients when resolving WS URI's).

But you can't make usage of DNS a MUST. While it generally is acceptable
over the wide Internet, it's almost always anti-pattern on internal
networks. Application developers in particular can never rely on this
because the guy who manages the DNS is not the same who manages servers
and generally doesn't accept to add any input for an application that is
not in production. Similarly, DNS which announce "public" records for
some services will cause trouble to local clients which would always
make use of the DNS first because of the MUST, and would not be able
to connect to the local address:port which is not announced anywhere.

If someone were to develop a backup/restore solution based on WS, it would
be funny to discover that it cannot be used to restore the DNS server when
this one fails...

However in my opinion it could be good to document a recommended DNS
architecture for WS, that is judged optimal and the most interoperable.
This could clearly be a separate RFC suggesting how clients and server
can make use of DNS SRV records for HA and LB.

> XMPP RFC's create "sip" and "xmpp-server" values.

Then maybe the name should be reserved as soon as the protocol spec is
released, and the document should refer to it.

> clients MUST resolve WS destinations.

MAY

> But that is not true now as WS

It does not even say that. It only talks about DNS when suggesting how
a client may select a limit on the number of concurrent connections (#5.1).

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 21 Jul 2011 19:52:57 +0200

2011/7/21 Dave Cridland <[email-masked]>:
> It's proven impossible, despite effort, to retrofit SRV onto HTTP; there is
> no way it'll be possible to retrofit onto WS.

Right. If WS borns with no SRV (as a MUST for WS clients) then just
forget it and let inherit all the ugly limitations from HTTP protocol.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: David Endicott <[email-masked]>
Date: Thu, 21 Jul 2011 14:01:05 -0400

I am strongly opposed to any MUST definition for any type of URL resolution.

I'm ok with inheriting / mimicking HTTP.    Since it is intended to live in
the same universe as HTTP, I'm ok with it sharing mechanisms / limitations.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 21 Jul 2011 20:10:24 +0200

> I am strongly opposed to any MUST definition for any type of URL resolution.

SIP and XMPP mandate (MUST) a resolution mechanism based on NAPTR, SRV
and A/AAAA records. Are they also wrong? do you also oppose to the DNS
MX resolution (as mandatory) for a mailto: URI? Do you imagine that a
mail server admin could not assume that SMTP clients would always use
MX resolution as the first choice? annoying that you say that, sorry.

> the same universe as HTTP, I'm ok with it sharing mechanisms / limitations.

Yes, I assume many people in the HTTP warden is fine with this. That
is the problem: forcing a *new* protocol to inherit ugly limitations
just because "people is used to them". I don't understand how you can
prefer to ignore cool NEW solutions/mechanisms. This should not be a
valid argument in a new protocol design.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: David Endicott <[email-masked]>
Date: Thu, 21 Jul 2011 14:43:07 -0400

I do not know SIP or XMPP well enough to comment on why they mandated the
name resolution mechanisms they did.    However, XMPP is used in a highly
dynamic host environment, so having flexible & extensible name resolution is
likely an excellent choice.

I do not oppose DNS's MX records for SMTP as email addresses are name@domain,
so obviously the Domain Name System is appropriate.    Also, I fail to see
why a mail admin should care how the SMTP clients arrive at the server.  DNS
MX is a reasonable solution, but there may be other methods, any and all of
which are irrelevant to the SMTP server.    Especially when the SMTP server
supports multiple email domains....

Since WS is intended as a browser supported protocol, WS should follow the
same URI resolution mechanisms as HTTP (or how URI resolution is done in
general)  Having URLs that could resolve differently for a HTTP request and
a WS setup is a problem.

However....I agree in the sense that I don't think it's been well thought
out what the ramifications are of introducing a new URI *scheme*.  (ie.
ws:// and wss://)    Since everything after the double-slash is "scheme
specific", defining a scheme implies many things (including name resolution
policies, well-known ports, transport protocols, etc.)   But, I don't want
to get side tracked over this.

---

From: David Endicott <[email-masked]>
Date: Thu, 21 Jul 2011 16:57:23 -0400

>
> I have no idea what you might mean by "highly dynamic host environment" in
> this context, but XMPP servers are normally found at the same location
> consistently. However, it is *not* always (or typically) the same location
> as a simple A record lookup:
>

That's what I meant.  XMPP systems have hosts that change around (for many
reasons) and having a name resolution that handles that is good.

> This property alone is very useful - in a websockets case this would mean
> being able to provide websockets services from a different host (or network)
> to the traditional web services in a simple manner, fully compatible with
> SOP.   The fact that this also allows cheap lightweight load balancing and
> fallback control is also useful in other cases; none of this relates to
> dynamic hosts, but simply richer service location.

Yes, those are all excellent reasons to use DNS SRV.   None of them are a
reason to mandate that WS require it.   Because something is good for some
(or many) use cases, does not mean it is appropriate for everything and
certainly is not a reason to mandate it as a requirement.
 System implementer should be free to pick and choose tools and mechanisms
appropriate for their tasks.   DNS SRV would likely be an excellent choice
for many people.   But it should not be the one and only choice.   That's
really all I'm saying - don't force people to use something without an
overwhelming reason to make it the only option.

>> supports multiple email domains...
>>

You can be as theoretical as you like, by all means, but in practical terms,
> your email address (and my XMPP address) work because they use a defined,
> interoperable, service location mechanism, which operates via DNS record
> lookup.
>

Imagine I'm a SMTP server.   People connect to me.   They do SMTP
transactions.    I do not care how they found me.   Perhaps they used DNS to
find the MX server.  Perhaps they had it cached from before.  Perhaps they
guessed.  Perhaps it's in a hosts file.   I don't care.     I answer VRFY
and RCPT TO commands as appropriate.   If the "name" they are trying to
mailwith is one I recognize, I process it.  If I don't, it's an error.
Just because DNS-MX said that @foobar was handled at <addr>, doesn't mean
the dave@foobar is going to work.

Yes, DNS MX is a well known mechanism for determining what SMTP server to
connect with, but like I tried to say above, it's not mandated by the SMTP
protocol.   DNS MX is independent of SMTP and the two mechanisms
operate separately, but with a common goal.  I can use DNS to resolve a name
and never send email/message.  I can send a email/message via SMTP and never
use DNS to resolve a name.    Or I can use one to do the other.

When a SMTP server handles mail for multiple domains, the SMTP server has to
process the @domain part of the RCPT TO request - DNS is not involved at
that point.   This process is unrelated to any DNS MX definitions.    I used
that as an example of how some name resolutions are sometimes done outside
of any DNS framework.

>>  But they do resolve differently anyway. You don't get a page from a 'ws'
> scheme URI, you get a transport protocol connection. This is good, indeed,
> it's kind of the point.
>

Do they?   A http uri and a ws uri have the same host/path construction.
 It's really only the scheme that differs - and that identifies the
transport protocol to be used.   Resolution of host name/addresses and
mapping of paths "should" be consistent.

WS is a connection that is semantically related to the URI of the request.

e.g. I could ws://host/davesaid  and get live traffic of what Dave is
saying, and then I could ws://host/bobsaid  and get traffic of what Bob
says.  I wouldn't get Bob on /davesaid and I wouldn't get Dave on /bobsaid.
   Dynamic content identified by a URI

And if I http://host/davesaid  I could get a <li> of what Dave said.
Static content of a URI.

It could be problematic if  ws://host/davesaid resolves to a different
address than http://host/davesaid.     (Or it could be advantage - not for
us to decide, however)

> Your suggestion of "how URI resolution is done in general" is somewhat
> self-defeating, too, since aside from 'http' and 'https', there are
> 'mailto', which uses MX, 'sip' and 'xmpp', which both use SRV.
>

As you just said, the universe is bigger than just xmpp, sip, and http.

>
> I think opponents of SRV records need to mount a stronger argument than the
> kind of luddite argument that if it's hard for one protocol in use by the
> browser, it should be hard for them all.

I think you misinterpret my position.  And I resent the luddite slight.   I
think DNS SRV is an awesome tool and would greatly benefit many
implementations.

My position is that it should not be a *requirement*.     It should be an
optional mechanism that can be used if desired.   Further, since WS is a
bastard cousin to HTTP, they should share a similar name resolution
mechanism.

>  - acap://acap.dave.cridland.net/**byowner/user/dwd/bookmarks/<http://acap.dave.cridland.net/byowner/user/dwd/bookmarks/>

---

From: Dave Cridland <[email-masked]>
Date: Thu, 21 Jul 2011 22:46:37 +0100

On Thu Jul 21 21:57:23 2011, David Endicott wrote:
> environment" in
But that statement makes no sense.

Firstly, XMPP servers simply *don't* change around. Really. I don't  
think Google's servers have changed since the service launched:

;; ANSWER SECTION:
_xmpp-server._tcp.gmail.com. 26125 IN	SRV	5 0 5269  
xmpp-server.l.google.com.
_xmpp-server._tcp.gmail.com. 26125 IN	SRV	20 0 5269  
xmpp-server1.l.google.com.
_xmpp-server._tcp.gmail.com. 26125 IN	SRV	20 0 5269  
xmpp-server2.l.google.com.
_xmpp-server._tcp.gmail.com. 26125 IN	SRV	20 0 5269  
xmpp-server3.l.google.com.
_xmpp-server._tcp.gmail.com. 26125 IN	SRV	20 0 5269  
xmpp-server4.l.google.com.

The *clients* move, but they're *doing* SRV resolution, in order to  
locate the servers for their domain.

Secondly, there's nothing dynamic or magical about SRV lookup; the  
records are no more or less static than any other. SRV handles  
roaming hosts as targets no better or worse than A records,  
therefore. All SRV adds is a way of adding indirection, host/port  
discovery, and pushing fallback and load balancing toward the client.

I'm concerned that you may have critically misunderstood what SRV  
records are useful for.

> overwhelming reason to make it the only option.

SRV records simply can't be bolted on afterwards. That's been proven  
with HTTP itself. That's an overwhelming reason, in my opinion.

> the dave@foobar is going to work.
Erm. OK...

In the real world, people do care that their mailserver can be found,  
and so they publish MX records, in the confidence that other mail  
servers will use them. This is similar to being a webmaster and  
wanting your website to be found, thus putting A records in. But  
cleverer.

Now, I agree that, in theory, it would be possible to not bother with  
DNS, and simply ask people to put your hostname into their hosts  
files, but you know, I don't think this would work as well, and it's  
certainly not an argument against SRV. (Iñaki's proposal, as I  
recall, even has fallbacks to allow server administrators to avoid  
SRV records in some cases).

> use DNS to resolve a name.    Or I can use one to do the other.
In practical terms, the MX record and SMTP are interlinked. Moreover,  
RFC 5321 says:

   Only resolvable, fully-qualified domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or address (i.e., A or AAAA) RRs (as  
discussed
   in Section 5) are permitted, as are CNAME RRs whose targets can be
   resolved, in turn, to MX or address RRs.  Local nicknames or
   unqualified names MUST NOT be used.

So there is an argument that it does, indeed, mandate DNS.

> that as an example of how some name resolutions are sometimes done  

But the name resolutions are done in exactly the same way, whether  
the mailserver handles one or many domains.

So a mail administrator must ensure that MX records for all the  
domains point to the mailserver host.

> mapping of paths "should" be consistent.
So you're expecting xmpp://[email-masked] to do what,  
exactly? Because it doesn't do an A record lookup of isode.com, for  
starters.

> address than http://host/davesaid.     (Or it could be advantage -  

I have no idea what any of this means, but it sounds largely  
theoretical, and orthogonal to the point at hand.

Let's put it in practical terms.

'ws' and 'http' URIs have to be treated in different ways.

Therefore, we can treat them in different ways.

> somewhat
Erm.

Yes.

What this has to do with SRV record usage in websockets is entirely  
beyond me.

> bastard cousin to HTTP, they should share a similar name resolution

My argument is that it cannot be made optional, so if we want to ever  
take advantage of this "awesome tool", we need to bake it in from the  
start.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 21 Jul 2011 22:52:07 +0100

> be funny to discover that it cannot be used to restore the DNS  
If SRV (with a fallback) is defined as part of the core spec, this  
usage would use the fallback.

> can make use of DNS SRV records for HA and LB.

Okay, a thought experiment for you.

Let's assume we go ahead with dumb A/AAAA lookups.

How will it be possible for a server to later inform browser it  
wishes to use SRV lookups?

If you have an answer for this, we can make it optional, and moreover  
we can deploy SRV for HTTP as well.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 21 Jul 2011 23:21:07 +0100

On Thu Jul 21 23:15:59 2011, Bruce Atherton wrote:
> So if you have no control over the DNS, it is not a problem. The  
> host will be resolved exactly the same way as it is now, using a  
> hosts file or A record or whatever. The only change is that the  
> client is required to try to use the more advanced mechanism if it  
> is available.
> 
> 
Right.

> I admit that I find it a little troubling to use MUST for the  
> client to follow this procedure as there is a burden on  
> implementers to understand how to code this since it isn't done by  
> default in the standard libraries the way that ordinary name  
> resolution is. Making it the recognized best practice with a SHOULD  
> would be preferable all else being equal.
> 
> 
SRV lookup is pretty commonplace now in libraries. XMPP and SIP  
clients have no difficulty finding this functionality in a wide  
variety of environments. For the web, where there are substantially  
fewer web browsers than there are XMPP clients, I don't think this  
would pose any kind of problem.

> It can be argued that not using a MUST may well open up  
> interoperability problems because some Websockets clients contact  
> the wrong host. However, keep in mind that in the older SIP RFC2543  
> it provided two resolution mechanisms. It specified that clients  
> SHOULD look up address records, but MAY use the DNS SRV mechanism.  
> SIP survived that without too much of a hassle. And specifying that  
> Websockets clients SHOULD use DNS SRV, but MAY use address records  
> alone looks like an improvement.
> 
> 
SIP survived because it was very small. I don't see WS making a  
transition, in the same way that repeated attempts have failed to  
move HTTP to SRV.

Dave.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Jul 2011 09:11:33 +0900

> It's proven impossible, despite effort, to retrofit SRV onto HTTP;

Where is a proof?

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Jul 2011 12:16:27 +1000

> > It's proven impossible, despite effort, to retrofit SRV onto HTTP;

Transitioning HTTP to use SRV is trivial even with proxies.

Transitioning HTTPS to use SRV is complicated because of proxies.
There needs to be changes to how clients talk to proxies for HTTPS
+ SRV to work through proxies.

HTTP and HTTPS's use of the DNS is a abomination.  CNAME is totally
misused.  If you want to host a service on another machine you use
a record that indicates that.  You don't use a alias because aliases
mean so much more.

Getting back to WS and SRV, WS needs to be SRV aware from day one
or it needs its own type in the DNS.  If you don't have SRV records
then you fallback to straight address records.

WS needs to specify what happens when a CNAME, literal or synthesised
from a DNAME, is returned in a DNS lookup.  Is "host.example.net
CNAME host.example.com" equivalent to "host.example.net SRV 100 0
0 host.example.com" or is the CNAME treated as a alias and the URL
gets re-written?

Take the case where one name really is a alias for the other.

	ws.example.net CNAME example.net
	_ws._tcp.example.net SRV 100 0 0 server.hoster.com.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Jul 2011 23:17:39 -0400

> then you fallback to straight address records.

I'm fairly convinced that in the vast majority of cases, SRV is a bad idea.  DNS is already too out of sync from hosts in many situations; SRV just makes the situation worse.  Or to put it another way, if you want to give every DNS admin the ability to impose fine-grained control over what all of the hosts named by his DNS zones can do, deploy SRV universally.  There are situations where this makes sense, but overall, giving that level of control to DNS administrators is an extremely bad idea.

That said, if this protocol is going to use SRV, it absolutely needs to do it from day one.  There's no way to retro-fit SRV to most protocols without breaking compatibility with existing implementations of those protocols.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Jul 2011 13:43:32 +1000

In message <[email-masked]>, Keith M
oore writes:
> >=20
> > In message <[email-masked]>, Masataka =
> Ohta writes:
> >> Dave Cridland wrote:
> >>=20
> >>=20
> >>=20
> >=20
> >=20
> >=20
> >=20
> I'm fairly convinced that in the vast majority of cases, SRV is a bad =
> idea.  DNS is already too out of sync from hosts in many situations; SRV =
> just makes the situation worse.  Or to put it another way, if you want =
> to give every DNS admin the ability to impose fine-grained control over =
> what all of the hosts named by his DNS zones can do, deploy SRV =
> universally.  There are situations where this makes sense, but overall, =
> giving that level of control to DNS administrators is an extremely bad =
> idea.

What a load of FUD.  SRV records are no differnet to CNAME/MX records
in terms of control.  We don't shy away from adding MX records for
email or CNAME records for HTTP when CNAME is used a SRV equivalent.

Note even with SRV you have fallback to A/AAAA records when no SRV
record is present.

> That said, if this protocol is going to use SRV, it absolutely needs to =
> do it from day one.  There's no way to retro-fit SRV to most protocols =
> without breaking compatibility with existing implementations of those =
> protocols.
> 
> Keith
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 00:32:23 -0400

> email or CNAME records for HTTP when CNAME is used a SRV equivalent.

SRV records at first glance like a straightforward generalization of MX records.  But in a sense, that's the problem.  One danger of SRV records is that because they are generic, people keep thinking that they should be retroactively applied to all protocols, whether it makes sense or not.  This is a huge slippery slope.  Not only is there a potential for SRV records to be applied to protocols for which they aren't well suited (which is to say, most protocols), but there will also be a temptation to use SRV to route traffic through NATs that do port mapping, by changing the ports on which those protocols operate from their defaults.  Combine this with multi-faced DNS, so that the port that a peer uses to talk to a service will vary according to from where the DNS query was made, and you get a huge mess.

A related problem is due to the tension between DNS names as hostnames, and DNS names as names for things besides hosts.   DNS started out (quite deliberately) as a system for naming only hosts, and it still reflects that heritage in several ways.   But people keep using it, understandably, to name services rather than hosts, or sometimes to use the same name both.  When a DNS name is exclusively used to associate a name with an IP address or set of IP addresses that provide a single service, that's not a problem.  But when a DNS name is used in some contexts to name a host and in other contexts to name a service, that invites problems.  When people take a DNS name that is used to name a host and then add SRV records for the same name, unless it's done very carefully, that disrupts use of that DNS name to refer to the host and protocol servers at that host.  

For email and MX records, it didn't make such a big difference because by the time MX records were in widespread use, workstations were replacing larger multiuser machines and it became natural to want to associate several hosts with a single email server and map all of them to a single email domain.   But that's a very specific use case.  MX records, in practice, really don't change the behavior of a protocol or host so much as allow domain names to be used for a purpose other than to name hosts - namely to associate email addresses from that domain with one or more SMTP servers willing to receive mail for them.  

(Even then, the problem of MX records being out of sync with the SMTP servers does exist, and used to be a significant source of mail delivery errors.)

CNAMEs are a mess for other reasons.  But at least they don't give DNS admins fine-grained control over individual protocols and services.  If the CNAME is screwed up, it's screwed up for everything associated with that domain.  That tends to call more attention to the problem.

> Note even with SRV you have fallback to A/AAAA records when no SRV

Right, but the DNS admin can blackhole or reroute traffic for your host by installing a SRV record that you don't want or that doesn't match reality.   Bad architecture.  There's a place for access controls and traffic filters, but it's not in DNS.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Jul 2011 14:01:54 +0900

> + SRV to work through proxies.

What's wrong with:

   https://www.example.com
   _https._tcp.www.example.com SRV 0 1 100 server.example.org

   CONNECT server.example.org:100 HTTP/1.1
   Host: www.example.com

?

> a record that indicates that.  You don't use a alias because aliases

What's wrong with:

   https://www.example.com
   _https._tcp.www.example.com SRV 0 1 100 server.example.org
   server.example.org CNAME cname.example.org

   CONNECT server.example.org:100 HTTP/1.1
   Host: www.example.com

?

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Jul 2011 15:47:39 +1000

>    server.example.org CNAME cname.example.org

Firstly SRV is not (yet) defined for HTTP.
 
>    CONNECT server.example.org:100 HTTP/1.1

I was referring to this sort of misuse.

	www.example.com CNAME server.web-hosting-service.com.

www.example.com really isn't a alias for server.web-hosting-service.com
If it was you could replace "www.example.com" with
"server.web-hosting-service.com" and be served the same content.

Or this misuse

	example.com SOA ...
	example.com MX ...
	example.com CNAME server.web-hosting-service.com.

which people try to do and causes all sort of problems.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 22 Jul 2011 10:51:08 +0100

> > It's proven impossible, despite effort, to retrofit SRV onto HTTP;

Sorry, I've a habit of using the word "proof" in the English (and  
indeed Welsh) sense of "test" or "trial", rather than the  
mathematical sense of the statement backed up by logic.

I should simply say that there have been attempts (I recall more than  
one draft), but the situation is sufficiently entrenched that these  
have gained no traction, in no small part because of the requirement  
for something close to a flag day.

1) There are no SRV records.

2) Therefore browsers do not support them.

3) Therefore you'd need to allow for A-lookup as fallback for the  
forseeable future.

4) Therefore there's no incentive for browsers to support SRV.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 22 Jul 2011 10:55:19 +0100

On Fri Jul 22 03:24:41 2011, David Endicott wrote:
> there are added inefficiencies.   Also the name resolution of the  
> HTTP that
> serves the Javascript that opens the WS should remain constant.    
> If WS
> resolves the host/domain to a different address than the HTTP it  
> was spawned
> from, it becomes a method to bypass same-origin / CORS restrictions.

That's an unfortunate misunderstanding.

All protocols that use SRV records maintain the target domain.

So a ws://example.com/xyz would still send a Host header of  
"example.com", whether SRV or not, so there is no impact on same  
origin policy, CORS, etc.

Dave.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Jul 2011 19:30:36 +0900

> 	example.com CNAME server.web-hosting-service.com.

Do you mean there is no complication of HTTPS+SRV by proxies?

> which people try to do and causes all sort of problems.

Your examples just do not work for people, which will drive them
solve their own problems by themselves.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Jul 2011 19:34:49 +0900

Dave Cridland wrote:

>> Where is a proof?
> 
> Sorry, I've a habit of using the word "proof" in the English

> 4) Therefore there's no incentive for browsers to support SRV.

That's a perfect proof against IPv6 deployment. Infrastructure
won't be updated.

However, for application layers issues like SRV ones, thanks to
the end to end argument, only servers and clients need
upgrading without infrastructure changes, which is why major
application of the Internet changed from ftp to http.

							Masataka Ohta

---

From: Scott Schmit <[email-masked]>
Date: Fri, 22 Jul 2011 08:31:14 -0400

> That's a perfect proof against IPv6 deployment. Infrastructure

Ironic you should mention that, because if more protocols supported SRV,
the content providers could have a lot more control over the IPv6
transition. For example:

_http._tcp.example.com. SRV 0 99 80 www.example.com.
_http._tcp.example.com. SRV 0 1 80 www-ds.example.com.
www.example.com. A 198.0.2.1
www-ds.example.com. A 198.0.2.2
www-ds.example.com. AAAA 2001:db8::2

I.e., content providers could control/measure their probability of
failure. As www-ds.example.com's success rate improves, its weight can
be increased.

-- 
Scott Schmit

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Jul 2011 22:41:25 +1000

> for something close to a flag day.

There is no need for a flag day.  If SRV support had been added
when first proposed there would be close to 100% by now.  Browsers
get regularly updated so there really is no reason to not add SRV
support.

The main reason to add SRV support is to provide indirection.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Jul 2011 23:36:10 +0900

Scott Schmit wrote:

> failure.

Are you saying content providers will actively control their probability
of failure from 99.99%> to 99% or 99.1% (assuming 10% IPv6 deployment)
only to promote IPv6?

							Masataka Ohta

---

From: Scott Schmit <[email-masked]>
Date: Fri, 22 Jul 2011 14:26:31 -0400

> of failure from 99.99%> to 99% or 99.1% (assuming 10% IPv6 deployment)

I'm saying that they can be IPv6-ready without affecting their bottom
line (at least, as they perceive it). Whether they will or not--as you
point out--is another thing altogether, but at least it takes away an
often-used excuse.

Also, I've seen comments along the lines of "I want to phase in the IPv6
traffic" this allows that to happen.

-- 
Scott Schmit

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 22 Jul 2011 15:44:19 -0700

> forget it and let inherit all the ugly limitations from HTTP protocol.

I am tired of this.  SRV is not used for HTTP because SRV adds latency
to the initial request for no useful purpose whatsoever.  SRV records for
XMPP and MX records for mail are useful because there is only one such
server expected per domain and it is *very* desirable to maintain central
control over that routing.  In contrast, HTTP is deployed in an anarchic
manner in which there are often several HTTP servers per machine
(e.g., tests, staging, production, CUPS, etc,).  AFAICT, WebSockets is
even more anarchic than HTTP -- it will have to be, given that the sane
network admins will block it by default.

In short, SRV is not used by the Web because it is inappropriate for HTTP.
I have seen no reason to believe that it would be appropriate for WebSockets.
If you want SRV to be part of the proposed standard, then you have to convince
the people implementing WS to use SRV.  None have done so, yet, so we can't
expect the editor to add it to the spec just because you have an opinion.

....Roy

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Jul 2011 19:18:21 -0500

On Jul 22, 2011, at 4:51 AM, Dave Cridland wrote:
> 3) Therefore you'd need to allow for A-lookup as fallback for the forseeable future.
> 

That's pretty much where we were when we grafted SRV onto SIP eleven and a half years ago, updating earlier SIP drafts (which lacked SRV support). There was no incentive for SRV support in SIP user agents at the time, either. 

See:

http://tools.ietf.org/html/draft-ietf-sip-srv-00

The first SIP RFC 2543 used SRV, but didn't work very well. RFC 2782 cleaned up the SRV process somewhat, but we required further documentation for SIP to make use of it effectively.  It eventually worked itself out as RFC 3263, which also involved NAPTR records and a slew of other DNS kludges. But barring the limitations of DNS (some people still want requester-variant answers), it works pretty well now.

But yes, there's more to effective target resolution than just saying "Use SRV records". Especially if you have multiple protocol choices, proxies,  aliases, and TLS in the mix.

--
Dean Willis

---

From: Philippe Bernard <[email-masked]>
Date: Thu, 21 Jul 2011 22:52:35 +0100

On Thu, Jul 21, 2011 at 9:57 PM, David Endicott <[email-masked]> wrote:
>> terms, your email address (and my XMPP address) work because they use a
>> defined, interoperable, service location mechanism, which operates via DNS
>> record lookup.
>>
>> I think opponents of SRV records need to mount a stronger argument than
>> the kind of luddite argument that if it's hard for one protocol in use by
>> the browser, it should be hard for them all.
>

Iñaki's proposal only imposes a requirement on clients, not on
server-side WS deployments, since clients will fall back to A/AAAA if
no SRV records are available. The mechanism (on the client-side)
cannot be optional though, it would make SRV for WS mostly useless in
practice.

-Philippe.

---

From: Bruce Atherton <[email-masked]>
Date: Thu, 21 Jul 2011 15:15:59 -0700

I think there is some misunderstanding as to what is being proposed, at 
least as I understand it. Iñaki, please correct me if I am wrong.

You are right that it would be impossible to require all environments 
that wanted to add Websockets support, whether client or server, to 
change their DNS to have NAPTR and SRV records. After all, Websockets is 
intended to integrate easily into the already existing HTTP infrastructure.

What is being proposed, though, is to require clients to resolve the 
hostname portion of ws: and wss: URLs by _first_ looking for NAPTR and 
SRV records (unless, of course, the hostname is already an IP address). 
If a NAPTR record is found, use it to look up an SRV record (otherwise 
use a default). If an SRV record is found, use it to look up the A or 
AAAA record. If no SRV record is found, look up the record exactly the 
same as if you were looking up an HTTP host, by using the host name from 
the URL.

So if you have no control over the DNS, it is not a problem. The host 
will be resolved exactly the same way as it is now, using a hosts file 
or A record or whatever. The only change is that the client is required 
to try to use the more advanced mechanism if it is available.

I admit that I find it a little troubling to use MUST for the client to 
follow this procedure as there is a burden on implementers to understand 
how to code this since it isn't done by default in the standard 
libraries the way that ordinary name resolution is. Making it the 
recognized best practice with a SHOULD would be preferable all else 
being equal.

It can be argued that not using a MUST may well open up interoperability 
problems because some Websockets clients contact the wrong host. 
However, keep in mind that in the older SIP RFC2543 it provided two 
resolution mechanisms. It specified that clients SHOULD look up address 
records, but MAY use the DNS SRV mechanism. SIP survived that without 
too much of a hassle. And specifying that Websockets clients SHOULD use 
DNS SRV, but MAY use address records alone looks like an improvement.

As for where the enhanced location definition should live, I think a 
separate document is the best choice. No need to hold up this one.

On 21/07/2011 11:01 AM, David Endicott wrote:
> I'm ok with inheriting / mimicking HTTP.    Since it is intended to 
> live in the same universe as HTTP, I'm ok with it sharing mechanisms / 
> limitations.
>
>
>
> On Thu, Jul 21, 2011 at 1:52 PM, Iñaki Baz Castillo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     2011/7/21 Dave Cridland <[email-masked]
>     <mailto:[email-masked]>>:
>     <[email-masked] <mailto:[email-masked]>>
>
>
>
>

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 22 Jul 2011 00:29:52 +0200

Hi Dave,

> usage would use the fallback.

Which would be indicated by which component since the DNS is down ?

> wishes to use SRV lookups?

The same way it has been stated that browsers should use AAAA records
before A records when they exist. At one point it will be possible to
say "if an SRV record exists, then the browser should preferably use
it".

My point is not that DNS is not useful, just that in *some* cases, it
is all but desirable. Have you ever wondered why every cisco router
on the planet has "no ip-domain-lookups" in its config ? Basically
because core infrastructure component must be able to run with very
low dependencies, and DNS certainly is one dependency that is not
desirable for a number of core infrastructure components. And there
is no reason why those components could not be WS clients.

> we can deploy SRV for HTTP as well.

It's not that easy either for HTTP. As I said in an earlier mail, HTTP
(as well as WS) has something special called proxies, which exempt
clients from having to deal with DNS. The simple fact that the server
does not know if the client will be able to use the DNS or rely on a
chain of intermediaries that may use it in various ways is a problem
for making use of DNS extensions mandatory.

You couldn't make DNS SRV mandatory for WS when WS starts with a protocol
upgrade from HTTP which does not mandate use of DNS SRV : the DNS resolving
had to be performed by the HTTP chain well before the connection gets
upgraded to WS. If any existing HTTP component in the chain does not make
use of DNS SRV, everything falls apart.

Experience has shown that a spec is not a way to force the world to change
to accomodate its requirements, rather it's a way to tell the world how to
adopt it at a reasonable cost and effort. The higher the expectations, the
lower the adoption. The most important thing is that the spec is designed
to support smooth upgrades so that real world usage drives it forwards.

Best regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 22 Jul 2011 01:19:41 +0200

> certainly is not a reason to mandate it as a requirement.

Hi David, I will be away for some days until I can read all the new
mails in this thread (I'll do it and will reply in a few days).
In the meanwhile I strongly ask you to read the draft about DNS SRV in
WebSocket:

Sepecially some sections:

   1. Introducion

   [...]

   DNS SRV mechanism facilitates network applications scalability
   without requiring an intermediary node distributing the traffic in
   load-balancing or failover fashion.  Instead, DNS SRV mechanism just
   requires a proper DNS setup.

   By introducing DNS SRV records into WebSocket protocol
   [I-D.ietf-hybi-thewebsocketprotocol], WebSocket providers can,
   optionally, take same advantages and provide scalable services with a
   minimal infrastructure.

   This specification mandates the usage of DNS SRV resource records by
   WebSocket clients when resolving a "ws:" or "wss:" URI [RFC3986], but
   still leaves the decision of using SRV records up to the service
   administrator.

  3. Implementation

  [...]

   It is up to the system administrator whether to set, or not, DNS SRV
   resource records for the WebSocket protocol within the provided
   service.  This specification allows the system administrator to use
   the DNS SRV [RFC2782] mechanism to improve the service reliability by
   providing load-balancing and failover capabilities, but does not
   mandate it (the system administrator could choose whichever
   scalability strategy).

Section 4 "Client Usage" in which is shown how the WS client should
perform SRV resolution just in case the WS URI is a domain and no port
is present in the URI:

   To clarify it, a WebSocket URI like "ws://example.org/myservice"
   requires the client to perform SRV resolution while
   "ws://example.org:80/myservice" does not (as the port is explicitly
   present in the URI).

   step 3:  If there is no SRV result, attempt the fallback process described
       in Section 4.2 and omit next steps.

   4.2.  Fallback Process

   The fallback process SHOULD be a normal A or AAAA address record
   resolution to determine the IPv4 or IPv6 address of the URI host
   component (or URI host value without DNS resolution if it contains an
   IP address).

   The server connection port is obtained as stated in Section 3.1 of
   [I-D.ietf-hybi-thewebsocketprotocol].

NOTE: The section 3.1 has changed in the new WS draft. It pointed to
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06#section-3.1
(3.1.  Parsing WebSocket URIs)

Also, the section 5 (Examples) should clarify it even more.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 22 Jul 2011 01:22:15 +0200

2011/7/22 Bruce Atherton <[email-masked]>:
> You are right that it would be impossible to require all environments that
> wanted to add Websockets support, whether client or server, to change their
> DNS to have NAPTR and SRV records. After all, Websockets is intended to
> integrate easily into the already existing HTTP infrastructure.
>
> hostname portion of ws: and wss: URLs by _first_ looking for NAPTR and SRV
> records (unless, of course, the hostname is already an IP address). If a
> NAPTR record is found, use it to look up an SRV record (otherwise use a
> default). If an SRV record is found, use it to look up the A or AAAA record.
> If no SRV record is found, look up the record exactly the same as if you
> were looking up an HTTP host, by using the host name from the URL.

Well, in SIP there are NAPTR records because SIP can work over
different transports (UDP, TCP, TLS-TCP. SCTP, TLS-SCTP). In case of
WebSocket, it just defined for TCP so NAPTR records don't make sense.

So just SRV is required:

a)  _ws._tcp.DOMAIN.COM    for WS URI
b)  _wss._tcp.DOMAIN.COM   for WSS URI

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 22 Jul 2011 01:27:20 +0200

> address than http://host/davesaid.     (Or it could be advantage - not for

David, this does not make sense at all. Let see this case:

a) mailto:[email-masked]
b) xmpp:[email-masked]
c) sip:alice@google,com
d) http://google.com
e) ws://google.com

Do you really expect that all those URI's should point to the same
server??? not, right? then, why e) should behave like d)?

And of course, protocols defining a kind of URI (specific for such
protocol) CAN and probably MUST also define how to locate such URI
destination. In case of http just poor A/AAAA is done, but in other
cases we all do know that other kind of DNS queries are done.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 22 Jul 2011 01:31:32 +0200

> use of DNS SRV, everything falls apart.

I understand that the websocket client is *co-located* within the
webbrowser client, but it's a different entity. Nothing prevents it in
using a different DNS mechanism.

Honestly I'm not reading good arguments against DNS SRV for WebSocket
protocol. Perhaps the topic about the HTTP proxies, but there should
be some way to deal with it without forcing WebSocket to inherit all
the limitations and poor capabilities of HTTP (when referring to
scalability and failover).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bruce Atherton <[email-masked]>
Date: Thu, 21 Jul 2011 16:47:41 -0700

> would pose any kind of problem.

Oh, it isn't hard, but it violates the principle of least surprise. Most 
people think they know how to code name resolution by using 
gethostbyname() or equivalent. And to do it efficiently, especially when 
we are operating in a world that is predominantly driven by HTTP 
servers, requires complexities like dealing with asynchronous calls to 
fetch the A and SRV records at the same time under the assumption that 
the SRV record probably won't exist.

>> interoperability problems because some Websockets clients contact the 
>> wrong host. However, keep in mind that in the older SIP RFC2543 it 
>> provided two resolution mechanisms. It specified that clients SHOULD 
>> look up address records, but MAY use the DNS SRV mechanism. SIP 
>> survived that without too much of a hassle. And specifying that 
> transition, in the same way that repeated attempts have failed to move 
> HTTP to SRV.
>
> Dave.

As I understand it, the issue that caused the various drafts for HTTP 
SRV to die without getting much traction is one of efficiency. It is 
inefficient to make all these extra DNS calls, especially when it is 
unlikely that many of the records you are blocking on will exist. Other 
than the inefficiency, HTTP SRV is just an incremental technology you 
add to your existing DNS without hurting what already exists. Since 
Websockets uses the same infrastructure the records are unlikely to 
exist for it either, so the inefficiency issues are still present.

Hmm, I seem to be arguing myself out of supporting DNS SRV as the 
preferred location mechanism. That is not the case. I just think that we 
face some of the same challenges migrating Websockets to SRV as are 
faced by HTTP because we share the same environment for the most part. 
Willy's example of a proxy that doesn't know how to resolve host names 
using the SRV method is a good example. But by advocating for the 
deployment of SRV records as a best practice for Websockets, we may 
improve things in the HTTP world as well. It is a shame there is no 
standard defined for HTTP SRV to point to.

---

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 22 Jul 2011 00:14:25 +0000

[As an individual]

I think the lack of DNS SRV for HTTP could also be because of the guidance in http://wiki.tools.ietf.org/html/draft-iab-dns-applications-02#section-4 that argues that DNS might not be the best approach for *all* HTTP applications. Perhaps also for WS applications...

It could be a good alternative to have, so I agree with pursuing it as a separate option in a different document.
	
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bruce Atherton
> Sent: Thursday, July 21, 2011 16:48
> To: Dave Cridland
> Cc: Server-Initiated HTTP; IETF-Discussion
> Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The
> WebSocket protocol) to Proposed Standard
> 
> Oh, it isn't hard, but it violates the principle of least surprise. Most people think
> they know how to code name resolution by using
> gethostbyname() or equivalent. And to do it efficiently, especially when we are
> operating in a world that is predominantly driven by HTTP servers, requires
> complexities like dealing with asynchronous calls to fetch the A and SRV records
> at the same time under the assumption that the SRV record probably won't exist.
> 
> >
> As I understand it, the issue that caused the various drafts for HTTP SRV to die
> without getting much traction is one of efficiency. It is inefficient to make all
> these extra DNS calls, especially when it is unlikely that many of the records you
> are blocking on will exist. Other than the inefficiency, HTTP SRV is just an
> incremental technology you add to your existing DNS without hurting what
> already exists. Since Websockets uses the same infrastructure the records are
> unlikely to exist for it either, so the inefficiency issues are still present.
> 
> Hmm, I seem to be arguing myself out of supporting DNS SRV as the preferred
> location mechanism. That is not the case. I just think that we face some of the
> same challenges migrating Websockets to SRV as are faced by HTTP because we
> share the same environment for the most part.
> Willy's example of a proxy that doesn't know how to resolve host names using
> the SRV method is a good example. But by advocating for the deployment of
> SRV records as a best practice for Websockets, we may improve things in the
> HTTP world as well. It is a shame there is no standard defined for HTTP SRV to
> point to.
>

---

From: David Endicott <[email-masked]>
Date: Thu, 21 Jul 2011 22:24:41 -0400

On Thu, Jul 21, 2011 at 7:47 PM, Bruce Atherton <[email-masked]> wrote:

>
> As I understand it, the issue that caused the various drafts for HTTP SRV
> to die without getting much traction is one of efficiency. It is inefficient
> to make all these extra DNS calls, especially when it is unlikely that many
> of the records you are blocking on will exist. Other than the inefficiency,
> HTTP SRV is just an incremental technology you add to your existing DNS
> without hurting what already exists. Since Websockets uses the same
> infrastructure the records are unlikely to exist for it either, so the
> inefficiency issues are still present.
>
> location mechanism. That is not the case. I just think that we face some of
> the same challenges migrating Websockets to SRV as are faced by HTTP because
> we share the same environment for the most part. Willy's example of a proxy
> that doesn't know how to resolve host names using the SRV method is a good
> example. But by advocating for the deployment of SRV records as a best
> practice for Websockets, we may improve things in the HTTP world as well. It
> is a shame there is no standard defined for HTTP SRV to point to.
>

I find myself reminded of my reservations about HTTP Upgrade as the opening
handshake.  It is clever, efficient and reflects some of the shared nature
between HTTP and WS.   However, I felt it should be considered one of
several mechanisms for opening a WS connection, one especially suited for
a co-mingled environment.   But not explicitly the only such method.  (I was
unable to convince many of my position on that, so I could very well be in
the minority about this issue as well)    I think DNS SRV is in a similar
area.   It's a useful technology that if the client uses could be of
benefit.   I'm just not convinced there is overwhelming cause to make it a
mandatory requirement.    Saying that nobody will use it if it's not
legislated does not strike me as a good enough reason.   The technological
advantages are worthy, when it's used, but when it doesn't come into play,
there are added inefficiencies.   Also the name resolution of the HTTP that
serves the Javascript that opens the WS should remain constant.   If WS
resolves the host/domain to a different address than the HTTP it was spawned
from, it becomes a method to bypass same-origin / CORS restrictions.

I favor a minimalist core with extensibility.    Name resolution happens
before the WS opening handshake, so I continue to see this as outside the
domain of the WS protocol.   I would prefer that name resolution be provided
by a selectable method.  That way, in 20 years, when name resolution needs
have again changed, we'll have the ability to adapt.

---

From: John Tamplin <[email-masked]>
Date: Thu, 21 Jul 2011 22:45:17 -0400

> have again changed, we'll have the ability to adapt.

How about some language like "SHOULD use SRV records to locate the
host unless specifically configured for an alternate name resolution
method"?  I think that leaves open the possibility for clients that
know better to do so, but strongly encourages most client
implementations to use SRV records.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 22 Jul 2011 12:51:03 +1000

I agree that DNS SRV is a matter outside the scope of  websockets,
which (for better or for worse) use a connection that is established
via a HTTP request.   Thus I do not think that the establishment of a
HTTP connection for websockets should differ in any way from the name
resolution handling of other HTTP connections made by a user-agent.
If the advocates of DNS SRV wish for websocket to use it, then they
need to convince HTTPbis (I think that is the right WG?) to adopt it
for all of HTTP and then websockets will inherit that feature.

If in future, there is a proposal to directly establish websocket
connections without a HTTP upgrade (as David Endicott has alluded to),
then I think DNS SRV should definitely be supported.

regards

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 22 Jul 2011 07:43:45 +0200

> b)  _wss._tcp.DOMAIN.COM   for WSS URI

Iñaki, what we're saying is that the resolving applies first to HTTP
well before it is WS. For instance, a client could connect to an HTTP
server, fetch a few objects, then decide to upgrade the connection to
switch to WebSocket. DNS resolving for WS would not even be involved
here.

I agree with what others have been saying : if/when a different handshake
is supported, eg. on a specific port without the HTTP upgrade, then it
will make sense. But as of now we're relying on the lower layer. As Greg
said it, without a deep change in HTTP you won't be able to make the rule
a MUST for WS. However, John's suggest of using a SHOULD when the record
exists and the client can see it looks fine. What's the problem if not all
of your clients go to the same hosts ? You can even announce all of your
servers with A/AAAA and with SRV as well as long as they're running on the
same ports. Those who can use SRV just have more information than the other
ones and can be served better.

Regards,
Willy

---

From: David Endicott <[email-masked]>
Date: Fri, 22 Jul 2011 09:39:53 -0400

Good to know, thank you.

On Fri, Jul 22, 2011 at 5:55 AM, Dave Cridland <[email-masked]> wrote:

> So a ws://example.com/xyz would still send a Host header of "example.com",
> whether SRV or not, so there is no impact on same origin policy, CORS, etc.
>
>
> Dave.
> --

---

From: David Endicott <[email-masked]>
Date: Fri, 22 Jul 2011 09:47:31 -0400

>> whether SRV or not, so there is no impact on same origin policy, CORS, etc.

Actually....I wasn't talking about the Host: header - that is totally
spoofable...I was concerned about:

1. Browser client resolves example.com via old style DNS to x.x.x.x and
fetches HTTP
2. Received HTML starts JS which starts WS connection
3. WS resolves example.com via DNS SRV to y.y.y.y and opens
4. WS now has access outside origin.

Please note, I did not specify why DNS SRV resolved differently than old
style DNS - could be malicious, could be an simple mistake.     I am
assuming the DNS SRV and old DNS might be answered from different servers.

Do browsers restrict origin / cross-site access based on name or on address?

---

From: Ted Hardie <[email-masked]>
Date: Sat, 23 Jul 2011 14:41:11 -0400

> assuming the DNS SRV and old DNS might be answered from different servers.
You definitely could set it up such that the results from an SRV lookup
points to a different server than that resulting from a lookup of AAAA or A;
that's kind of the point.  The SRV lookup is to a service within the
original domain, but the resulting looking up could have results outside it.
 To go back to Dave Cridland's example, you can see that the result of the
SRV is another name requiring lookup.

;; ANSWER SECTION:

You'd have to avoid the results triggering the antibodies to a cross-site
scripting attack in order to deploy this well, in my opinion.

regards,

Ted

---

From: Mark Andrews <[email-masked]>
Date: Sun, 24 Jul 2011 07:23:22 +1000

> recognized best practice with a SHOULD would be preferable all else 
 
No.  MUST is what is needed.  It's a new protocol.  Do what's best from
day one.

---

From: Keith Moore <[email-masked]>
Date: Sat, 23 Jul 2011 19:24:58 -0400

> No.  MUST is what is needed.  It's a new protocol.  Do what's best from

Sort of agree.  If use of SRV for this protocol is really appropriate (which I doubt, but I haven't looked at it closely) then the protocol specification should say "MUST use SRV".
If use of SRV for this protocol is not appropriate, or if it's not clear that it's appropriate, then the specification should probably say "MUST NOT use SRV". 

Either way, provide clear direction to implementors and don't leave the decision as to whether to use SRV up to the implementation.  That would create different behaviors in different implementations, which is clearly not desirable.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Sun, 24 Jul 2011 17:33:23 +1000

In message <[email-masked]>, "Roy T. Fielding" writes:
> On Jul 21, 2011, at 10:52 AM, I=F1aki Baz Castillo wrote:
> 
> >> It's proven impossible, despite effort, to retrofit SRV onto HTTP; there=
>  is
> > =
> to the initial request for no useful purpose whatsoever.

How do you solve the problem of hosting just "http://example.com/"
on "s1.joes-web-service.com" and not redirect everything else at
example.com?  People have been complaining about this for about as
long as the web has existed.

> SRV records for
> I have seen no reason to believe that it would be appropriate for WebSocket=
> s.
> If you want SRV to be part of the proposed standard, then you have to convi=
> nce

---

From: Dave Cridland <[email-masked]>
Date: Sun, 24 Jul 2011 10:35:45 +0100

> switch to WebSocket. DNS resolving for WS would not even be involved
I get where you're coming from.

You're saying that you have a nebulous connection thing, that you  
pump HTTP requests down, and you may want to use that for WebSocket  
upgrade requests as well, by taking the ws URI and performing a  
simple transformation on it into an HTTP URI to make the upgrade  
request on.

So, given ws://example.com/foo/bar, you'll make the upgrade request  
on http://example.com/foo/bar

What Iñaki and I are arguing for is that for WS, there is simply one  
additional step prior to finding a suitable connection, which is  
performing an SRV lookup/selection.

And this new step can actually be performed before any of the HTTP  
connection steps. So, roughly, in order to "do" WebSocket for  
ws://example.com/foo/bar you would first do SRV lookup, which would  
give you an equivalent HTTP URI to perform the upgrade request. So  
for example, if you got:

_ws._tcp.example.com SRV 1 0 ws.example.com

You'd make the upgrade request on the HTTP URI of:

http://ws.example.com/foo/bar

Of course, if this failed to connect, you can find another HTTP URI  
to try - something you cannot do without SRV.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 24 Jul 2011 11:20:28 -0400

> there is no way it'll be possible to retrofit onto WS.
In my capacity of a WG participant:
+1

---

From: Hector Santos <[email-masked]>
Date: Sun, 24 Jul 2011 12:36:44 -0400

> application of the Internet changed from ftp to http.

Where is a proof?  :)

A Major Application will offer all services necessary for the customer 
to leverage. They are not going to eliminate ftp just because the 
"developer" likes http better or whats customers to switch to http. 
Even then, where I have seen a history of people using a http link, I 
have also seen many changed back, if only to help balance or spread loads.

My personal technical input on SRV.  It works when particular 
applications needs them or have become dependent on them in order to 
resolve connectivity. i.e. xmpp. But to me, there is an awful lot of 
waste and redundant lookups just to resolve an uri.  It would appear 
to me for web sockets, due to its intended market place of returning 
interactive I/O applications now over the web and specially mobile and 
wireless networks, the less overhead the better.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: amadou ouabanaize sidi ali <[email-masked]>
Date: Sun, 24 Jul 2011 17:46:17 +0100 (BST)

Dear All
I nead documentations about DNS et IPv6 architecture and implémentation
Thanks 

AMADOU OUABANAIZE Sidi Ali
Ingénieur d'Etat en Informatique
Enseignant à l'Université de Tahoua
BP:256 Tahoua (Niger)
Cel: +22796893540 / +22794025704 / +22790385974

________________________________

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 24 Jul 2011 10:56:41 -0700

On Jul 24, 2011, at 4:42 AM, Iñaki Baz Castillo wrote:

> 2011/7/23 Roy T. Fielding <[email-masked]>:
> And I'm really tired of hearing the argument of the "latency" which
> nobody demostrates (but just talks about it without replying me how
> the same is not a problem in realtime protocols like SIP and XMPP).

Try using a protocol analyzer.  It is a problem with SIP and XMPP.
Chat and telephony have different user expectations about the initial
connect time, so people just don't notice it as much as they do when
a web page rendering process stalls because embedded resources require
two additional DNS requests.

>> server expected per domain
> 
> $ host -t srv _xmpp-server._tcp.gmail.com
> _xmpp-server._tcp.gmail.com has SRV record 5 0 5269 xmpp-server.l.google.com.
> _xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server3.l.google.com.
> _xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server2.l.google.com.
> _xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server4.l.google.com.
> _xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server1.l.google.com.
> 
> No comments.

I meant server as in authority to answer for the domain, of course.

>> and it is *very* desirable to maintain central
>> control over that routing.
> 
> I don't know what this means.

It means that admins care a great deal about what machines in the network
are allowed to receive mail for that network, and likewise for XMPP, since
both are store and forward protocols that contain messages with personal
information for individual addresses which are routed on a hop-by-hop basis.
HTTP has none of those characteristics.  Hence, Mail and XMPP are centralized
services for an entire domain, whereas HTTP services are specific to the
services provided by each individual host.

>>  In contrast, HTTP is deployed in an anarchic
>> (e.g., tests, staging, production, CUPS, etc,).
> 
> Could you explain me why DNS A is good but DNS SRV is bad in such
> "anarchic" deployments?

Because DNS A for a server is deployed as soon as the server is made
available on the network (Intra or Inter).  It is one of the first things
done when installing an OS.  SRV, in contrast, requires that the zone
manager reconfigure DNS.

>>  AFAICT, WebSockets is
> ------------------------
> ------------------------

*shrug*

> Ok, so the argument "I don't know SRV but I feel fine with HTTP
> limitations for years" will win. Great design decissions.

No, the argument is that I know SRV, I know a lot more about HTTP, and I know
for a fact that SRV is not desirable for HTTP.  So, whenever you suggest that
lack of SRV is somehow a failing of HTTP, you should understand that it makes
your arguments look clueless.  Please, find some other example.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 24 Jul 2011 11:19:06 -0700

> long as the web has existed.

The Web has existed in usable form since 1991.  Name-based virtual
hosting wasn't even possible until we added Host in 1995.  In any case,
nobody has ever asked me to make the above a priority -- it simply isn't
a relevant problem compared to load balancing in general, and the general
problem does not assume that the client is friendly.

I would never try to "solve" load balancing by requiring every browser
to make an additional (failed) DNS SRV request each time it encounters
one of the 357,292,065 individual hostnames that are known to use HTTP,
not to mention the many millions more that are not exposed on the
Internet and don't even use DNS for resolution.  HTTP would not, cannot,
and never will benefit from SRV even if we had a magic wand that could
deploy it on all browsers.  SRV simply doesn't fit the Web architecture.

....Roy

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 24 Jul 2011 20:35:15 +0200

* Iñaki Baz Castillo wrote:
>Open the fastest web page and tell me how long it takes.

Too long.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Dave Cridland <[email-masked]>
Date: Sun, 24 Jul 2011 21:18:40 +0100

On Sun Jul 24 19:59:49 2011, Willy Tarreau wrote:
> On Sun, Jul 24, 2011 at 08:30:11PM +0200, Iñaki Baz Castillo wrote:
> > 2011/7/24 John Tamplin <[email-masked]>:
> > >> ~100 ms (if the DNS server is not local and there is no DNS  
> cache for
> > >> the given domain). And just during the WS connection, no more.  
> Taking
> > >> into account that a WS will be *usually* connected after  
> loading a web
> > >> page, such ~100ms in a non-full-realtime protocol is  
> insignificant.
> > >
> > > Wait, are you really saying that 100ms connect latency is  
> unimportant?
> >
> > Open the fastest web page and tell me how long it takes. Probably  
> you
> > have performed a DNS A query. I don't think that a xtra DNS query
> > would be the bottleneck, never.
> 
> 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.

I think what might be colouring your opinion regarding DNS resolution  
times on mobile is the difference between the first and subsequent  
RTTs.

3G sessions, in a reasonable area, drop to around 100-150ms, although  
they can go up to 300ms or higher if the network condition  
deteriorates. However, the setup of DCH, the radio state normally  
used for internet traffic (and needed for DNS requests and  
responses), takes a healthy number of round-trips, so that the first  
RTT is about three times longer.

Moreover, it's not clear to me that SRV lookup always (or even  
commonly) adds an additional round-trip. Take an XMPP client SRV  
lookup to my own server:

$ dig _xmpp-client._tcp.dave.cridland.net SRV
;; QUESTION SECTION:
;_xmpp-client._tcp.dave.cridland.net. IN	SRV

;; ANSWER SECTION:
_xmpp-client._tcp.dave.cridland.net. 86400 IN SRV 5 2 5222  
peirce.dave.cridland.net.

;; AUTHORITY SECTION:
dave.cridland.net.	86400	IN	NS	br.cridland.net.

;; ADDITIONAL SECTION:
peirce.dave.cridland.net. 86400	IN	A	217.155.137.61
peirce.dave.cridland.net.  
86400	IN	AAAA	2001:470:1f09:882:2e0:81ff:fe29:d16a

Note that the addresses of the actual server are returned in the  
additional section. My understanding is that in practical terms  
this'd always happen for in-zone cases. (If there's a large number,  
you may not get them all, since they can be discarded without error,  
but it practise you're likely to).

Finally, as I've said before, I think that any overhead involved is  
going to be swallowed up in the noise of general session startup in  
the WebSocket case. I do appreciate things are at the very least  
perceived as different in the HTTP case, although I think SRV would  
help solve issues (like off-site failover) there, too, but I think  
the moment you have long-running stateful sessions, you'll end up  
with the same impact to user experience of a few extra RTTs at  
startup as is seen in XMPP, SIP, and so on - that is, none.

100ms extra on a 100ms request/response would be bad, I agree, but  
that's not what we're talking about.

Dave.

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 12:52:23 +0200

[ should we leave [email-masked] in CC or not ? I'm suspecting that people
  who read this address will quickly get bored by hybi traffic ]

> on http://example.com/foo/bar

No I'm not saying that because I don't understand what you mean here.
What I'm saying is that browsers try to reuse existing connections to
host:port. So if you want to connect to ws://example.com/foo/bar and
the browser already has a connection to example.com:80 because of a
previous HTTP request to that host, it's much advantageous for it to
reuse that existing connection.

Making an additional DNS request and a connection come with a cost.
In mobile environments, it's not uncommon to see 300-500 ms RTT. This
means that performing the additional DNS request could cost up to one
extra second.

> performing an SRV lookup/selection.

That's clearly what I understood.

> to try - something you cannot do without SRV.

If the connection fails here, HTTP will fail too, and right now, people
don't use SRV records with HTTP. I'm not judging whether it's good or
bad, I'm just saying what I'm seeing. Instead, people are using load
balancers, BGP and DNS mechanisms to ensure their site is available.

So whatever principle they're currently using with HTTP will also
provide the same mechanism for free to WS.

Yes it could be nice to have SRV on both HTTP and WS, but we need to
make it adopted for HTTP first. And if it's not adopted at all in the
case of HTTP, probably that is because it's not perceived as bringing
a lot of benefit *for that specific usage*. Instead it may even add
one DNS round trip which clearly is not desirable with highly interactive
protocols such as HTTP.

Also, the notion of "failure to connect" is hard to qualify in interactive
environments. If my browser tries to connect and waits more than a few
seconds before retrying on another server, I will probably already have
pressed the Esc key. We all do that when clicking links on Google search
results : if you don't get a result in one second, you click another one.
It is not reasonable to use even lower timeouts when using SRV records,
because it happens quite often to lose packets on the net, and sometimes
it's the client side which is slow. If the browser decides to fail within
one second and try another host, it will experience very frequent
difficulties.

Client-based failover (what SRV or MX are) is nice with protocols that
can wait long enough to ensure the server is dead. Some mailers try to
connect for one minute or even more. At that point, the client is
certain that the server is dead. In a browser, nobody waits that long,
so giving such a verdict is quite hard.

Still, I think that SRV might be used for site failover, it will be a
lot cleaner than using very short TTLs as some are doing. Such a usage
is compatible with deployed infrastructures, because nothing prevents
a client from prefering an SRV record over a CNAME record.

Now with that in mind, I don't see how one could suggest a MUST for this.
MUST that don't directly come from absolute requirements are never 100%
respected and cause much more trouble than SHOULD which are recommended
for optimal usage. If we say SHOULD, sites will ensure they have a working
DNS config which always announces valid addresses in A/AAAA or CNAME and
that SRV is used for failover. If we say MUST, sites won't bother emitting
correct addresses in A/AAAA or CNAME, or will even announce different ones,
and we'll get a lot of trouble at many places where the wrong record will
be picked by proxies or by clients which can't use SRV for whatever
reason.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 13:02:48 +0200

Hi Mark,

> long as the web has existed.

I would say that people complaining about this are doing the wrong thing
first. We've been using www.domain.tld, ftp.domain.tld, mail.domain.tld,
ns.domain.tld for ages, each indicating the service in their host name,
and suddenly just because www.domain.tld appears in the browser's address
bar, it should be shortened to show only "domain.tld". If people are doing
this, they must assume their choices. Sure, SRV would make that easier for
them, but it's not as if no solution had existed before.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 14:07:51 +0200

On Sun, Jul 24, 2011 at 01:26:53PM +0200, Iñaki Baz Castillo wrote:
> Hi. Maybe I'm the only who assumes that, usually, the WS server is not
> colocated within the initial web server.

Web-based infrastructures make that almost mandatory at the frontend,
especially in massive hosting where you don't want to multiply IP addresses.
In general you have one single point which handles the IP:port and which
dispatches that to many servers based on the Host header, URI, file names,
cookies, etc...

> This is, your text below is valid just in the case I browse a web page
> in http://some-domain.org (so port 80) and retrieve a WS URI to
> connect to ws://some-domain.org (so also port 80). In that case you
> say that the http/ws client would decide to upgrade the connection so
> "it must assume that the WS handshake must be sent to the same IP:port
> resolved for the HTTP communication".
> 
> I don't agree with yout point. Doing the "upgrade" does not mean
> reusing an existing TCP connection (in which HTTP took place) for
> other purpose.

Huh ?

> Instead, doing the WS upgrade means opening (or
> reusing) a TCP connection, sending a HTTP GET with special semantics,
> expect 101 and then start a bidirectional frame-based communication.

I still remember how the handshake works, thank you.

> So sending the GET with "upgrade" has nothing to do with any previous
> HTTP communication with the HTTP server.

Yes it has. Either you open a fresh new connection, or you reuse an
idle existing one. But to know that the connection is idle, you must
understand the protocol that was spoken on it and this protocol must
have clearly delimited messages. HTTP supports reuse of connections
(also called "keep-alive") and since the WS handshake is HTTP, it is
possible and I'd add even recommended to reuse an existing connection
to send a WS handshake, if one such connection exists.

> > will make sense.
> Do you mean WS as a complete separate protocol running on a specific
> WS port and so? I'd really would like it (rather than the exotic
> pseudo-HTTP mechanism used right now), but I expect it will never
> happen.

I'm sure it will happen. We need applications to be developped using
WS first. But there are places where :
  - HTTP compatibility won't be needed
  - masking will be annoying
  - HTTP overhead will be too much
  - HTTP round trip will be too much

I think that this will happen as soon as a working proposal for TLS NPN
appears, because the same requirements will exist (eg: how to specify
the resource name in a simpler way, etc...). Right now we need WS to be
able to replace long polling mechanisms which already work over HTTP, so
if we want it to be adopted, we need to deploy where previous methods
used to work. You just need to be patient :-)

> > But as of now we're relying on the lower layer. As Greg
> Having multiple A/AAAA records for a single domain does not provide
> failover (as clients usually take just the first IP). I see your
> point, but I expect no success at all.

That's not what I'm saying. Right now, people are using A/AAAA with short
TTLs and are updating the zones when a site fails (when I mean a site, I
mean a datacenter). This is something which happens rarely enough to be
acceptable. Using fast DNS updates for server failover does not work
because caches are everywhere and experience shows that even after one
month you still receive traffic on a server you've stopped announcing.

However, please read what I've explained in another mail about the
limitations of client-based failover in web environments.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 14:11:47 +0200

On Sun, Jul 24, 2011 at 01:47:36PM +0200, Iñaki Baz Castillo wrote:
> 2011/7/24 Willy Tarreau <[email-masked]>:
> http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02#section-5.2

You still need the DNS request : the client does an A/AAAA request for
the HTTP host, then if you ask it to use an SRV record for the WS connection,
it must perform that request too, even if it's to conclude that it can reuse
the idle connection.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 14:16:22 +0200

> the same is not a problem in realtime protocols like SIP and XMPP).

Because you have never worked in a mobile phone environment. You'd be
amazed to see what end users are paying for ! Count 300-500 ms on average
for a DNS request.

> Could you explain me why DNS A is good but DNS SRV is bad in such

DNS is not mandatory for HTTP. It's not "DNS A" which makes it good, but
"no mandatory DNS". This is a huge difference.

Regards,
Willy

---

From: John Tamplin <[email-masked]>
Date: Sun, 24 Jul 2011 10:13:50 -0400

On Sun, Jul 24, 2011 at 7:11 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> 2011/7/22 David Endicott <[email-masked]>:
> > The technological advantages are worthy, when it's used, but when it
> doesn't
> > come into play, there are added inefficiencies.
>
> ~100 ms (if the DNS server is not local and there is no DNS cache for
> the given domain). And just during the WS connection, no more. Taking
> into account that a WS will be *usually* connected after loading a web
> page, such ~100ms in a non-full-realtime protocol is insignificant.

Wait, are you really saying that 100ms connect latency is unimportant?

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 20:33:43 +0200

On Sun, Jul 24, 2011 at 08:25:05PM +0200, Iñaki Baz Castillo wrote:
> Ok, but I don't consider a xtra DNS query to be so hard.

I had to perform sites analysis for a customer a few months ago. Many
web pages nowadays have between 100 and 200 objects to fetch, spread
over up to 25-30 host names. If you take even only 100ms for each of
them, you're at 3 additional seconds to display the page. Granted those
requests are not WS and only HTTP, but as I said, SRV for WS won't work
before it works with HTTP, at least due to proxies.

But those 3 extra seconds will always be considered a good reason not
to make SRV mandatory for HTTP. The web is degrading very quickly due
to poor practices, and we should be careful not to suggest to make it
even worse.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 20:45:37 +0200

On Sun, Jul 24, 2011 at 08:24:25PM +0200, Iñaki Baz Castillo wrote:
> > idle existing one.
> If the WS URI points to a different server, it's perfectly possible
> that the WS connection has nothing to do (neither cookies usage) with
> the previous HTTP/HTML traffic. I just meant it.

I agree, and there will certainly be a large number of cases where it
will be different. But that's not enough (in my opinion) to make something
mandatory considering the negative side effects.

> > But to know that the connection is idle, you must
> Don't take me wrong, but "keep-alive" mechanism in HTTP is just a hack
> since paralelism is not possible (well, it's but with too many
> constrains, for example the server must send the replies in order).

Pipelining improves things a lot, especially for static objects which
immediately fill the pipe.

> In
> other protocols working on top of TCP (as SIP) each request contains
> an id (in the case of SIP the Via branch) which allows identifying
> which request a response belongs to, so I can send N requests via the
> same TCP connection and receive the responses in any order.

>From what I've read, SPDY typically addresses this point.

> HTTP is poor on this topic, and I wouldn't like WS to inherit it.

But it will since there is no MUX support yet, WS frames will be delivered
in order. The application on top of WS might decide to number each message
though and use its own out-of-order mechanism though.

> ok, I like what you say :)
> However, imagine that in next 2 years there are a lot of WS servers
> speaking HTTP (for the WS handshake, of course). If you suggest that a
> different WS protocol could appear, it would require a new URI schema
> so the client knows wheter to perform a HTTP WS handshake or use the
> new WS protocol.

That's just a minor detail. Likewise it will probably have to support a
fallback to the HTTP handshake because there will be a lot of places where
it will not pass through.

> And there is where DNS SRV could help a lot :)

Not that much, because as soon as you fail your DC, you'll stop announcing
it so that visitors don't try to connect there for seconds before they
detect it's down.

> Yes, I've read it. But I expect it's even more critical in a phone
> call (my SIP phone performs SRV/A, gets the first IP:port and sends
> the call request there using UDP, but the server is down, so after
> some seconds *without hearing ringing* the phone sends the call to
> another server). If it's not critical in SIP, why should it be so
> critical in WS?

As I said, having it in WS means having it in HTTP too. And having a
browser rely on TCP connection timeouts to decide to use a server vs
another one would make a lot of sites unusable. I've already been used
to mark some advertiser's sites as 255.255.255.255 in my /etc/hosts to
stop waiting for their crap to respond on pages that I'm used to visit.
If a page loads objects from s1,s2,s3,s4.domain.tld and all are hosted
both on a valid and a dead DC, it can take a lot of time before all these
hosts are marked down and ignored. Nobody I know would wait for these to
fail.

> Also, if the user realizes that the connection takes too much time and
> presses F5 to reload the page, why couldn't the webbrowser cache the
> SRV results and mark the previous attemp as failed so next server:port
> woul be tryed when the user presses F5?

Yes but once again, if you have to wait one minute on each new site so
that all dead servers can be ignored, the web will look like a terrible
experience to you.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 20:57:06 +0200

On Sun, Jul 24, 2011 at 08:28:49PM +0200, Iñaki Baz Castillo wrote:
> Well, mobile phone world is a pain due to GPRS/3G internet
> connections. But those networks should be improved rather than
> assuming that all the Internet must change to work on those infernal
> environments (which IMHO are not yet ready for modern internet). All I
> see in mobile networks are workarounds.

Those are infernal but part of the time cannot be compressed much more
due to the fact that you have to share the medium with many other people
and you have to wait for your slot to send packets. And I'm not even
counting the time it can take to forward your data across the country
between the antenna and the datacenter. Sure things will improve, but
I don't expect seeing anything below 40-50ms.

> So, do you mean using URI's with IP rather than domain? (take into
> account that TLS connection require the certificate to match the URI
> domain, but anyhow it's also possible to use IP's within the
> certificate).

On internal networks, using IP instead of URIs is not uncommon at all,
especially on developer networks where you need many instances of the
same server in different versions or for different people. Some static
servers also make use of this because it saves one roundtrip. And of
course you have it on your ADSL router's web-based configuration interface
otherwise you wouldn't be able to contact the DNS to reach the router :-)

But that's not what I meant, I meant that DNS is not the only solution
to resolve host names. WINS, NIS and /etc/hosts are usable too. When I
was a student in 94, we had all our passwords and hostnames in NIS and
no DNS was configured. It worked like a charm. DNS is not something
mandatory at all for many protocols. It just happens to be the standard
over the public Internet.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 20:59:49 +0200

On Sun, Jul 24, 2011 at 08:30:11PM +0200, Iñaki Baz Castillo wrote:
> Open the fastest web page and tell me how long it takes. Probably you

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.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 21:16:41 +0200

On Sun, Jul 24, 2011 at 08:52:32PM +0200, Iñaki Baz Castillo wrote:
> Ok. But I don't see the problem. What about Google Apps? My own domain
> uses Gtalk and Gmail by setting Google XMPP SRV and MX records. Now
> imagine that I would host my personal webpage (domain "www.aliax.net")
> in Google, wouldn't be great a SRV entry for HTTP
> (_http._tcp.aliax.net has SRV record 10 0 80
> web-server-01.google.com)? or do we prefer the ugly HTTP 30X
> redirection or ugly CNAME?

Well, you gave the perfect example : here, CNAME is the exact equivalent
of SRV. None is cheaper nor better than the other. You just find it ugly
because it's called CNAME.

> In my opinion SRV is not possible for HTTP since SRV appeared too
> late. That's the main and enough reason IMHO.

I'd see it differently : the balance between its extra costs vs the
expected benefits does not push in the direction to massively deploy
it. You know, it only takes 4-5 browsers to enable it and make the
whole web use it. Pat already explained why he doesn't want it.

> The fact that people is "confortable" enough with HTTP style-of-life
> (a specification of 1999) and does not want to deal with "new
> technologies" other than stuff and more stuff on top of HTTP, is not a
> good argument for me.

It's not a matter of new vs old technologies. We're not trying to
paint HTTP in a shiny color to impress friends. We're dealing with
deployed setups and users with high expectations, which are currently
more or less met and for which your proposal doesn't sensibly improve
experience but can sensibly degrade it for many people.

> HTTP is not the layer number 5 in OSI model.

Like it or not, it has inherited this role a long time ago because it
provides many advantages over plain TCP (such as easy reconnection,
authentication, etc...).

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 21:29:48 +0200

On Sun, Jul 24, 2011 at 08:57:45PM +0200, Iñaki Baz Castillo wrote:
> Ok, but what would be the failover solution then? any failover
> solution can take some time until redirects the client's request to a
> working server, it's not just a client problem.

This is already addressed by existing web architectures. DNS provides
geolocation and proposes you the closest working datacenter. BGP ensures
that this datacenter is always reachable via multiple links and multiple
providers. Load balancers on the site ensure that only valid servers are
used. I know some people who configure their load balancers so that a
server is removed from the pool less than 50ms after a failure or slowdown
has been noticed. You will never be able to offer that quality of service
using DNS only, because those 50ms are less than the time it takes for
most visitors to ping the site.

> Anyhow, don't forget that SRV is not just for failover, but also for
> load-balancing (you can state that a more powerful server-01 receives
> 80% of the traffic and server-02 the remaining 20%).

This is already addressed by DNS round robin and used by a lot of sites.
But keep in mind that DNS is used between *sites* and not *servers*. If
you use it for servers, you'll fail because you won't be able to silently
put them in maintenance without disturbing visitors. Load balancers are
used for servers. And between sites, people are not seeking imbalanced
distribution. If they really do, then it's easy using multiple addresses.

Don't take this as an attack (it is not), but you accused Roy of not
knowing SRV, but I think that you're not much experienced with web
infrastructures and that may be why you think that SRV is the *only*
solution to many problems that have been dealt with for ages.

I think your proposal could make sense with SHOULDs instead of MUSTs,
eventhough it's unlikely that it will be used for the latency reasons
that were suggested.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 21:32:30 +0200

On Sun, Jul 24, 2011 at 09:02:59PM +0200, Iñaki Baz Castillo wrote:
> Ok, I get your point now :)
> But, do current webbrosers resolve names using anything but DNS A?
> (well, I know that they use /etc/hosts). Anyhow, WINS / NIS /etc/hosts
> and such stuff just maps a hostname into a single IP. It's the
> equivalent of a DNS A resource record. Think about locating a mail
> server (MX is required), you need a DNS server.

... or a static entry (the "Smart Relay host" entry you see in on the DS
line in sendmail.cf). That's the case of any mail client in a campus, they
don't use DNS to send outgoing mail. And even within the mail relays and
servers, it's quite common to have a relaydomains file to map domains to
servers.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 22:42:36 +0200

> times on mobile is the difference between the first and subsequent  

Note that in the point above I was not even talking about RTT but
explaining to Iñaki that sometimes DNS can be slower than the rest
of the transfer due to losses and slow retransmits.

> deteriorates.

I agree. However it can get a lot worse as soon as you have even just a
little bit of traffic on your link (eg: objects fetched in parallel).

> However, the setup of DCH, the radio state normally  

Yes and depending on the equipments vendor, you may even experience
losses during this phase for several seconds. But I was really not
talking about such issues that add to the bad experience and should
not be considered as the norm.

> but it practise you're likely to).

That's very interesting. For an unknown reason, doing the same request
from here using either dig or host only retrieves the answer and not
the authority nor the additional sections.

> that's not what we're talking about.

To ensure nobody gets me wrong, I'm certain this can help solve issues
*if this is optional*. If it becomes a MUST, then the negative effects
will override the positive ones. In my opinion, the client should decide
whether to enable it or not. If architectures are built with that in
mind, then it will not be an absolute requirement, and migration to SRV
could happen smoothly just like migration to make the Host header mandatory
happened. What is needed is a way to avoid the extra DNS lookup in most
cases where the SRV record is not there. Coupling it with CNAME as I
proposed could be a reasonable solution. Surely other solutions are better.

But we have to keep in mind that for SRV to work, it cannot be made
mandatory because existing infrastructure simply does not support it.
This point alone is enough to kill the mandatory requirement. And once
optional, we have to promote its adoption with a perceived benefit for
the end user with almost zero cost. Mixing all those points with the
use cases of WS leaves little place for SRV, but maybe someone wants
to work on it and identify the *real* benefits then emit a draft.

Regards,
Willy

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Jul 2011 07:11:51 +0900

Hector Santos wrote:

> "developer" likes http better or whats customers to switch to http. Even 
> then, where I have seen a history of people using a http link, I have 
> also seen many changed back, if only to help balance or spread loads.

I'm afraid you are not distinguishing providers of intermediate
infrastructure and competing developers of various software used
on end systems. The differentiations between them are essential
to understand the Internet.

Roy T. Fielding wrote:

> HTTP would not, cannot,
> and never will benefit from SRV even if we had a magic wand that
> could deploy it on all browsers.  SRV simply doesn't fit the Web
> architecture.

SRV is a tool for port based real/virtual hosting, which is why it
has increased its usefulness with IPv4 address exhaustion.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Jul 2011 08:48:28 +0900

Willy Tarreau wrote:

> over up to 25-30 host names.

How long does it take to fetch all the contents of 100 or 200 objects?

> If you take even only 100ms for each of

It's merely additional 100ms.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Jul 2011 08:58:41 +0900

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Jul 2011 09:04:11 +0900

> mandatory because existing infrastructure simply does not support it.

Such argument is valid at the IP, the infrastructure, layer where
IPv6 is to work but is not applicable at the application layer
where SRV is to work.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Jul 2011 10:46:58 +1000

In message <[email-masked]>, Willy Tarreau writes:
> On Sun, Jul 24, 2011 at 08:25:05PM +0200, I=F1aki Baz Castillo wrote:
> > > the HTTP host, then if you ask it to use an SRV record for the WS conne=
> ction,
> > > it must perform that request too, even if it's to conclude that it can =
> reuse
> > > the idle connection.
> > =
> 

No. It takes 100ms extra.  Only if you serialise all the lookups
does it take 3 extra seconds.  If you are not doing the DNS lookups
in parallel today you are already doing a dis-service to your
customers.

Adding a SRV lookup should add 0ms if it isn't there as you should be
making A, AAAA and SRV lookups in parallel.  Non-existance is as
cachable as existance is.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Jul 2011 11:12:46 +1000

In message <[email-masked]>, Willy Tarreau writes:
> On Sun, Jul 24, 2011 at 09:02:59PM +0200, I=F1aki Baz Castillo wrote:

But the Smart Relay host uses MX records.  The Smart Relay host should
be seen as the same as a HTTP proxy.

---

From: David Conrad <[email-masked]>
Date: Sun, 24 Jul 2011 15:49:33 -1000

[I haven't been following hybi and haven't read the draft, but as this is posted to the ietf list and there are a bunch of assertions here about the DNS I consider ... odd, I thought I'd chime in]

On Jul 24, 2011, at 8:59 AM, Willy Tarreau wrote:
> A lost UDP packet is not retransmitted nor signaled as lost, so the browser has to retry.

This sounds like a seriously broken resolver.  All resolvers I'm aware of have timeouts and retry if no response is received within the timeout. A resolver that gives up after a first time out is equivalent to a TCP stack that doesn't retransmit a SYN.  A bug should be filed with the vendor.

On Jul 24, 2011, at 9:16 AM, Willy Tarreau wrote:
> CNAME is the exact equivalent of SRV.

No. According to the RFCs and most implementations, you can't have CNAME with other data (A, MX, SOA, NS, etc).  With SRV, you can have anything at the same label.

> None is cheaper nor better than the other.

CNAME results in the resolver doing additional work, generally resulting in no need for an additional query but is not applicable in all situations (e.g., putting a CNAME at a zone apex is a gamble). SRV is far more general solution with additional benefits (e.g., priority) but requires an additional query.  The two RR type solve different problems.  CNAME is an alias for a host.  SRV provides information about services at a host.

On Jul 24, 2011, at 9:29 AM, Willy Tarreau wrote:
> DNS provides geolocation and proposes you the closest working datacenter.

No it doesn't.  The DNS _may_ provide a reasonable facsimile to geolocation if and only if the resolver is co-located with the requester. In a world of Google DNS, OpenDNS, ISP-wide anycast resolvers, etc., the assumption that the location associated with the IP of a DNS query correlates to the IP address of the HTTP initiator becomes increasingly dangerous.

>> Anyhow, don't forget that SRV is not just for failover, but also for load-balancing

> This is already addressed by DNS round robin and used by a lot of sites.

Only at the grossest level. What a client get back from a query depends on who has queried the same cache and authoritative server and what policy the authoritative server has for returning answers.  In reality, 'round robin' is 'random'.  This is qualitatively different than the prioritization offered by SRV.

Regards,
-drc

---

From: Keith Moore <[email-masked]>
Date: Sun, 24 Jul 2011 22:47:39 -0400

> long as the web has existed.

Well, in a way, that's what NAPTR was for.  All of the UR
i resolution mechanisms (equally applicable to DNS-based URIs) that were developed and never really used grew out of the original realization in the early 1990s that CERN could stop hosting the original web pages if it wanted to, and there was no way to keep those links from going stale.

The problem never went away, but the DNS-based solutions were defined a long time ago and never used.   By now, I think the market has long since decided.  For better or worse, the mechanism the market chose to use with the web was HTTP redirects.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Jul 2011 12:59:14 +1000

In message <CABLsOLD-KM6DnR8HvfGH8N1M=[email-masked]>
, John Tamplin writes:
> 
> On Sun, Jul 24, 2011 at 8:46 PM, Mark Andrews <[email-masked]> wrote:
> 
> But you have to wait until the SRV returns even if the A/AAAA response comes
> back first, so there is a non-zero cost even with an optimal implementation.
> I am not arguing whether the cost is worth the benefits, only that there is
> a cost in any case.

In 99.9999% of cases the three answers will come in within 1ms of
each other and you may be waiting on the A or AAAA record.  It
really doesn't take any longer to answer a SRV query compared to a
A or AAAA query.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Jul 2011 13:21:36 +1000

In message <[email-masked]>, Keith M
oore writes:
> i resolution mechanisms (equally applicable to DNS-based URIs) that were =
> developed and never really used grew out of the original realization in =
> the early 1990s that CERN could stop hosting the original web pages if =
> it wanted to, and there was no way to keep those links from going stale.

NAPTR is not defined for HTTP.
SRV is not defined for HTTP.
 
> The problem never went away, but the DNS-based solutions were defined a =
> long time ago and never used.

No.  It was explitly NOT defined.

RFC 2782
Applicability Statement

   In general, it is expected that SRV records will be used by clients
   for applications where the relevant protocol specification indicates
   that clients should use the SRV record. Such specification MUST
   define the symbolic name to be used in the Service field of the SRV
   record as described below. It also MUST include security
   considerations. Service SRV records SHOULD NOT be used in the absence
   of such specification.

> By now, I think the market has long =
> since decided.  For better or worse, the mechanism the market chose to =
> use with the web was HTTP redirects.

If the market hasn't has a really opportunity do decide as only one
mechanism has been specified and coded.  Most people don't know of
the existence of SRV or that it would be useful for HTTP.

If the only tool you have is a hammer then you use a hammer even
if a screwdriver would be better.

Mark

---

From: Keith Moore <[email-masked]>
Date: Sun, 24 Jul 2011 23:33:04 -0400

> No.  It was explitly NOT defined.

Ok, fair enough.   Those of us who were working on the DNS-based URI resolution mechanisms realized that they could be applied to http URIs in addition to almost anything else (NAPTR is incredibly flexible if you don't mind doing lots of DNS lookups).  But they were never formally adopted.

But if you really want to use DNS to do redirects for http: URIs (or for that matter ws: URIs or almost any other kind of URI), NAPTR was tailor-made to do that.  SRV was not.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Jul 2011 14:35:42 +1000

In message <[email-masked]>, Keith M
oore writes:
> >> i resolution mechanisms (equally applicable to DNS-based URIs) that =
> were =3D
> >> developed and never really used grew out of the original realization =
> in =3D
> >> the early 1990s that CERN could stop hosting the original web pages =
> if =3D
> >> it wanted to, and there was no way to keep those links from going =
> stale.
> >=20
> >> The problem never went away, but the DNS-based solutions were defined =
> a =3D
> Ok, fair enough.   Those of us who were working on the DNS-based URI =
> resolution mechanisms realized that they could be applied to http URIs =
> in addition to almost anything else (NAPTR is incredibly flexible if you =
> don't mind doing lots of DNS lookups).  But they were never formally =
> adopted.
> 
> But if you really want to use DNS to do redirects for http: URIs (or for =
> that matter ws: URIs or almost any other kind of URI), NAPTR was =
> tailor-made to do that.  SRV was not.

"_http._tcp.example.com SRV 100 0 80 <server>" is not a redirect.
The http client still issues "Host: example.com" not "Host: <server>".
If you want to do DNS level redirect of "www.example.com" to
"example.com" then NAPTR would be the way to do that and the http
client issues "Host: example.com" instead of "Host: www.example.com".

If web browers were using CNAME records correctly, i.e. as aliases,
then they would be treated as a DNS level redirect not as "return
the address of CNAME target but otherwise ignore that this is a
alias".  Doing this has all sorts if implications.  A lot of the
IDN issues are a direct result of HTTP clients/adminstrators abusing
CNAME.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Jul 2011 14:50:37 +1000

In message <[email-masked]>, Willy Tarreau writes:
> On Mon, Jul 25, 2011 at 10:46:58AM +1000, Mark Andrews wrote:
> > making A, AAAA and SRV lookups in parallel.
> 
> This does not work for a simple reason : you have to perform the lookups
> on the SRV response just as you would do with a CNAME :

Please re-read my claim as your comment is not applicable to it.

Mark

---

From: John Tamplin <[email-masked]>
Date: Sun, 24 Jul 2011 21:06:37 -0400

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 25 Jul 2011 06:29:21 +0200

And only now I can resolve xmpp-server.l.google.com and get its real address.
That's why I was saying that SRV and CNAME really are equivalent in terms of
latency, because both of them require an additional round trip.

And that is assuming that all the hosts are referenced on the main page, which
in practice is not true because a number of them are also in additional CSS
and JS.

Now if I want to be really picky, I'd add that at 100 bytes on average per
request, sending 30 additional requests means a total of 3kB of data on the
uplink, which require :
  - 1.5 second of uplink traffic on a 3G HDSPA link with 16kbps uplink
  - 375 ms of uplink traffic on a 3G HDSPA link with 64kbps uplink
  - 187 ms of uplink traffic on an ADSL 512/128

I'm not trying to dismiss the usefulness of the mechanism, I just don't
like to hear that doing something additional comes at absolutely zero cost.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 25 Jul 2011 06:32:00 +0200

> be seen as the same as a HTTP proxy.

Exactly, which means that the browser can't be required to rely on any
information from the DNS since it does not necessarily have access to it
and other components which are not under our control might behave in a
different manner than what we'd like.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 25 Jul 2011 06:58:21 +0200

> This sounds like a seriously broken resolver.  All resolvers I'm aware of have timeouts and retry if no response is received within the timeout. A resolver that gives up after a first time out is e…

What are you saying ? Your browser embeds the resolved as a library, so when
I'm saying that "the browser has to retry", I mean the resolver part of the
browser has to retry.

> No. According to the RFCs and most implementations, you can't have CNAME with other data (A, MX, SOA, NS, etc).  With SRV, you can have anything at the same label.

This does not change anything, because the CNAME is on the hostname while
the SRV is on the service name, so there is nothing wrong with having both.

> Only at the grossest level. What a client get back from a query depends on who has queried the same cache and authoritative server and what policy the authoritative server has for returning answers.  In reality, 'round robin' is 'random'.

Yes but in practice, this randomness offers very smooth distribution.

>  This is qualitatively different than the prioritization offered by SRV.

Indeed this is different, but this does not mean there is a huge need for
the minor improvements provided by SRV in this context.

I'm not saying that SRV is useless but that it adds little value to HTTP
and even smaller to WS without HTTP, and comes at a non-zero cost, whatever
people are saying. I'm also certain that if a new record were to be invented
(eg: report the server's load in real time), there would be major proponents
to make it mandatory for everything because it would be what would save the
world from an upcoming disaster.

I'm convinced we can find good use cases for SRV combined with either HTTP
or WS once we admit it is optional and the user controls this option. Try
to imagine what you could do if you knew that 50% of your visitors would
consider your SRV records. Maybe you could use them to progressively test
service updates. You could possibly get a better distribution, or serve
a maintenance page to some of them during maintenance operations instead
of leaving them in the dark. You have to think what the benefit can be
for the user to enable the option, not how to push it down his throat.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 25 Jul 2011 07:01:01 +0200

> Please re-read my claim as your comment is not applicable to it.

Ah OK : "if it isn't there". Sorry for missing it.

Willy

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Jul 2011 10:24:31 +1000

In message <[email-masked]>, Willy Tarreau writes:
> > [I haven't been following hybi and haven't read the draft, but as
> > this is posted to the ietf list and there are a bunch of assertions
> > here about the DNS I consider ... odd, I thought I'd chime in]
> > 
> > This sounds like a seriously broken resolver.  All resolvers I'm aware of
> > have timeouts and retry if no response is received within the timeout. A
> > resolver that gives up after a first time out is equivalent to a TCP stack
> > that doesn't retransmit a SYN.  A bug should be filed with the vendor.
> 
> > No. According to the RFCs and most implementations, you can't have CNAME
> > with other data (A, MX, SOA, NS, etc).  With SRV, you 
> > can have anything at the same label.
> 

You are missing the point.   The following is illegal though some nameservers
allow you to load the zone.

	example.com SOA ...
	example.com CNAME ...

This is not illegal

	example.com SOA
_http._tcp.example.com SRV ...

Nor is a fictional HTTP record which adds the same level of
indirection as CNAME.
 
	example.com SOA ...
	example.com HTTP <server>

> > Only at the grossest level. What a client get back from a query depends on who has queried the same cache and authoritative ser
> ver and what policy the authoritative server has for returning answers.  In reality, 'round robin' is 'random'.
> 

But it adds a lot of value to everyone else using the DNS.  By HTTP
clients and adminitrators abusing CNAME to achieve what SRV achieves
cleanly they cause problems elsewhere.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 26 Jul 2011 10:00:51 +0900

> I'm saying that "the browser has to retry", I mean the resolver part of the

You should mean that the browser can control behavior of the
resolver.

If the resolver in the browser retries within a hundred ms:

> So yes, it can take several seconds to just resolve a host and then
> only a few hundreds of ms to retrieve

won't happen.

						Masataka Ohta

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 26 Jul 2011 11:47:48 +0200

> most visitors to ping the site.

Yes, but those are expensive server side solutions. I wouldn't like
that a scalable architecture requires so complex solutions (which are
not very suitable in case of usual web hostings). DNS SRV provides a
cheaper way of doing something similar (both ways can live together
thought).

> This is already addressed by DNS round robin and used by a lot of sites.

I consider that a hack.

> put them in maintenance without disturbing visitors.

SRV provides load-balancing and failover. I never said that SRV is a
solution for temporaly put in maintenance a server.

> Load balancers are

Right, but I'm used to scalable and big SIP infrastructures and DNS
SRV is used for that (along with server side solutions as SIP load
balancers). What I say is that web infraestructures cannot use SRV
mechanism so it's not valid for me that just current HTTP solutions
are valid for any other new protocol.

In contrast it seems that for many people the hacks existing in HTTP
world (www.facebook.com resolves to a single IP) is the only way to go
for a scalable infraestructure "so DNS SRV is not needed". Why so many
efforts in disallowing an *optional* mechanism like SRV? If somebody
does not like it, just don't use it.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 26 Jul 2011 11:58:41 +0200

2011/7/24 Willy Tarreau <[email-masked]>:
> whether to enable it or not.

But I don't understand how a client is supposed to decide by himself
how to resolve a URI destination. If I give you my vcard containing my
SIP/XMPP/MAILTO URIs, I must expect that you would use *standarized*
mechanisms to locate the server for each service. In fact, in all
these cases (SIP, XMPP; MAILTO) the URI domain can point to several
IP:port (due to NAPTR / SRV / MX DNS records).

BTW: I know that any web browser would first lookup at the /etc/hosts
file when an URI is introduced. This would "replace" a DNS A/AAAA
query. Maybe NIS or whatever could also be used for this. It does not
break SIP/XMPP/MAILTO URI's resolutions: Initially NAPTR / SRV / MX
query would be performed and, if there is no such record (or there is
so we get hostnames for which DNS A must be performed) then the client
can check /etc/hosts for the "A" resolution (domain -> IP).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 26 Jul 2011 12:04:44 +0200

2011/7/25 Keith Moore <[email-masked]>:
> By now, I think the market has long since decided.  For better or worse, the
> mechanism the market chose to use with the web was HTTP redirects.

That's common in HTTP world: too much "cool" stuff on top of it, and
too much noise and hacks below it.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 26 Jul 2011 12:08:20 +0200

> client issues "Host: example.com" instead of "Host: www.example.com".

Great explanation.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Jul 2011 11:28:06 +1000

In message <CALiegf=[email-masked]>
> solution for temporaly put in maintenance a server.

Happy eyeballs however does allow you to take a server out of production
and not really notice it.  Note webbrowsers have had the ability to do
this for as long as webbrowsers have existed.

Billions of dollars have been wasted globally for the sake of a few hours
work by webbrowser vendors.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 27 Jul 2011 08:37:54 +0100

> work by webbrowser vendors.

Seems to be a recurring theme - browsers could have easily performed  
probe tests to check for vulnerable proxies and disabled WebSockets  
(or negotiated masking), but that was ruled out long ago.

Dave.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 26 Jul 2011 21:28:50 +0200

Hi Iñaki,

On Tue, Jul 26, 2011 at 11:58:41AM +0200, Iñaki Baz Castillo wrote:
> how to resolve a URI destination.

This is well explained in RFC3986, #3.2.2. It enumerates a number of
exiting name registration methods and makes it clear that DNS usage is
not mandatory at all, only suggested. Also, it only exposes the fact that
names are resolved to addresses. It obviously does not make any asumption
on the DNS records to use for this either.

> If I give you my vcard containing my

I'd say that the common practice with DNS has always been to use A records
for IPv4, AAAA for IPv6 (or CNAME for any), unless explicitly stated
otherwise for the protocol's usage. Now you could have resolver libraries
which would try SRV before trying A/AAAA and this would be transparent to
the upper application layers.

> file when an URI is introduced.

I'm not a browser developer, but I think they might even simply rely on
the system's resolver. For instance, you might have an /etc/nsswitch.conf
or /etc/hosts.conf which indicates the priorities for the resolvers.

> This would "replace" a DNS A/AAAA

I don't know where you want to go with that example, but as I explained
it, if you want to have any chance of making SRV *usable* with WS (or
HTTP), you have to motivate both sides by showing them that :
  - it's better for them to use it than not to use it (both servers and
    browsers)
  - the additional cost of using it is negligible
  - there are no issues with not using it
  - leaving the choices to the intermediaries will not cause disruptions

I'm pretty sure that can be done, but clearly not the way it's been
presented till now.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 27 Jul 2011 07:25:49 +0200

> this for as long as webbrowsers have existed.

Mark, could you elaborate on this point ? Surely you're not talking about
the fact that a browser retries a failed connection, but I'm not not sure
what mechanism you're talking about.

> work by webbrowser vendors.

This analysis seems a bit simplified in my opinion. Nothing is completely
white or black.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 27 Jul 2011 11:43:58 +0200

2011/7/26 Willy Tarreau <[email-masked]>:
> if you want to have any chance of making SRV *usable* with WS (or

These are godd points, but I never wanted to propose SRV for HTTP as I
consider it's just unfeasible at this time (take into account the
ammount of HTTP clients in the world, as browsers, libraries in any
language and so on).

>  - leaving the choices to the intermediaries will not cause disruptions

This last point is hard to accomplish (I'm just talking about SRV for
WS, not for HTTP) because HTTP proxies should be capable of
determining that a GET request is in fact a WS handshake, and *just*
in that case perform SRV procedures over the domain (assuming that
there won't be SRV in the old, anti-fashion and technologically
limited HTTP world).

> I'm pretty sure that can be done, but clearly not the way it's been

If the requeriment for including SRV in WS is also including it in
HTTP then I surrender. I don't think it will never happen, neither I'm
an expert in HTTP for such kind of proposal.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 27 Jul 2011 12:17:57 +0200

> ammount of HTTP clients in the world, as browsers, libraries in any

That's where I think you're mistaken. As long as you think of it as mandatory
this will not be possible. When you think of it as optional and with an added
value, then you will progressively see clients adopt it and make use of it.
Since the beginning, you're proposing the option as mandatory "just because"
and not for a perceivable added value by both sides. The downsides then
outweigh the benefits. But maybe the benefits do not really exist after all,
otherwise a valid attractive proposal would already have been made by the
time we spent discussing it.

> there won't be SRV in the old, anti-fashion and technologically

Once again, if you expect *all* HTTP proxies to be able to do that, your
proposal fails. If you expect that at least *some* HTTP proxies will be
able to do that with a benefit, then something is possible. Let me repeat
it, technologies are adopted, not forced on users.

> an expert in HTTP for such kind of proposal.

Probably that starting by enumerating in a draft the benefits it could bring
would be a good start. You seem to be very well convinced that there are
benefits, so you're probably one of the few persons able to start such a
draft.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 27 Jul 2011 12:46:28 +0200

2011/7/27 Willy Tarreau <[email-masked]>:
> this will not be possible.

Hi Willy, as I've explained several times in these threads, if a WS
client is not mandated to perform SRV given a WS URI domain, then the
service provider cannot rely on SRV records. This is, let's assume
that a WS service provider offers a WS URI like "ws://mydomain.org",
with these records (simplifying):

- SRV:   1.1.1.1:80, 1.1.1.2:80, 1.1.1.3:90
- A:        1.1.1.1

So assuming that SRV is optional for clients, the provider does not
know how many clients would use SRV or just A. Imagine the service
provider expects millons of concurrent users. He must be ready to
receive all those users in 1.1.1.1 (if they don't use SRV). So the
service provider must build a complex/expensive balancer system in
server side (BGP and all that stuf) just for the case in which most of
the clients would not perform SRV procedures. So 1.1.1.1 would be in
fact a balancer with N hosts providing the WS service behind it.

At the same time, if clients use SRV then load-balancing and failover
would be automatically provided by the SRV capabilities. No need for
like-BGS solutions in server side.

So the question is: which service provider would spend resources, time
and efforts building two different load-balancing/failover systems?.
If a provider can build the "BGP" solution then it will not need SRV.
And another provider which cannot build a "BGP" solution could not
entirely rely on SRV capabilities as maybe most of the clients would
not use it.

In the other side, if service providers must be ready to accept all
the traffic in the IP resolved via single DNS A query, then nobody
would need SRV and webbrowsers would just remove it (the Mozilla
developer has already said in these threads that he won't implement it
"due to latency reasons").

Also the fact that DNS is not mandated by HTTP neither WS makes things
even worse. In contrast, in XMPP and SIP protocols DNS is mandatory
and also SRV procedures. If you are a SIP provider hosting the service
with domain "mydomain.org" you don't ever need to have a working A
record for mydomain.org, but just SRV (and optionally NAPTR). Or you
could just have A record and not use SRV at all. SIP client procedures
for locating servers (RFC 3263) mandate first trying SRV and then
A/AAAA, so things would work in any case.

So correct me if I'm wrong, but making SRV optional for clients (in
*any* protocol) is not something I consider feasible or useful.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 27 Jul 2011 14:45:45 +0200

> - SRV:   1.1.1.1:80, 1.1.1.2:80, 1.1.1.3:90

No, he would have :

 - SRV:   1.1.1.1:80, 1.1.1.2:80, 1.1.1.3:90
 - A:     1.1.1.1, 1.1.1.2, 1.1.1.3

> know how many clients would use SRV or just A.

That's mainly the point : the provider would offer a service which is
designed to work both ways and which a part of the users would experience
better due to their consideration of the SRV record.

> Imagine the service

Once again, the goal to make SRV adopted BY USERS is not to ensure that
it tries to cover all the server-side needs, but that it offers better
quality of service to USERS. That way USERS will massively adopt it and
server will one day be able to safely rely on it. Just like neither
Javascript nor cookies nor flash are mandatory, still all of them are
very common in practice and many service providers happily rely on them.

> entirely rely on SRV capabilities as maybe most of the clients would

You can't transform the Internet in one day after publishing one draft.
Look at the Set-Cookie2 header. It was a massive failure. It was thought
that the broken Set-Cookie header could be fixed by one new RFC, and
nobody adopted it. The reason is that it was proposed as a replacement.
I think that Opera might be the only browser to parse it. In contrast,
if your proposal is backwards compatible and incites users to enable it
on their side, then in a few years it can become a de-facto standard.

> "due to latency reasons").

That's why I explained that you have to find what other benefits *for
the end user* can be brought by this. End users are deciding, not site
owners.

> Also the fact that DNS is not mandated by HTTP neither WS makes things

That's why SRV cannot be made mandatory.

> In contrast, in XMPP and SIP protocols DNS is mandatory

Feasible yes, useful I don't know, and I'm not the one trying to argue
that it can add value. If it can bring value to the user, some users
will enable it despite the possible added latency. If it does not
bring them anything, they won't use it.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 27 Jul 2011 15:45:38 +0200

> very common in practice and many service providers happily rely on them.

Thanks for your useful comments (as always in these threads). Let me
just a question:

What do you mean with "USERS"? Do you mean home users in front of
their web browsers? or webbrowser vendors?
I don't think home users (neither professional users) has nothing to
decide here, they will not "resolve" the WS URI retrieved from a
webpage.
So we are talking about webbrowser vendors, right? and typically there
are no more than.... 10?

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 27 Jul 2011 16:03:02 +0200

> their web browsers? or webbrowser vendors?

Users in front of web browsers.

> decide here, they will not "resolve" the WS URI retrieved from a

I think you're wrong. Those are these users which ask for feature XXX or
YYY that they like because it brings them a better experience. If you can
find a real benefit for the end user, there will be an option in the browser
and some of them will enable it. It's just important to find how an end user
may benefit from making use of SRV tags when connecting to his favorite site
instead of using just CNAME or A/AAAA. Maybe being able to always connect to
less loaded servers would be appreciated, because some site maintainers will
start announcing new servers. Maybe there are solutions to provide better
geolocation using SRV than with A (ie: let the web browser decide which field
to use instead of relying on its resolver's IP address). Maybe it will be
possible for mobile users to automatically select a different port which is
not subject to annoying transparent proxies at their provider. I don't know.
You must think in terms of better experience which might be brought via
better quality of service. Surely a DNS record might provide information to
improve QoS based on the browser's decision.

> So we are talking about webbrowser vendors, right? and typically there

Browsers implement what their users ask for. They don't want to add features
that are not desired and make experience worse or reduce reliability. But if
users ask for something, they'll certainly implement it.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 27 Jul 2011 17:19:30 +0200

> users ask for something, they'll certainly implement it.

Well, I understand (and agree) most of your text, but I still think
that the URI resolution mechanism is something transparent for an
end-user. This is not like having FlashPlayer for showing annoying and
dancing menus in a web page XD. End-users ask for FlashPlayer (and
Android 2.3 has included it for example) but end-users won't ask for
"SRV procedures".

I would translate your arguments to "web developers", those who want
to provide scalable systems and for which having some kind of QoS
mechanisms (specially for mobile devices) is a great advantage. Of
course, if this happens then end-users would be happier :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 27 Jul 2011 17:37:26 +0200

> Android 2.3 has included it for example) but end-users won't ask for

They won't "ask for", but when some sites pretend "we work better with",
then they'll ask for the techno to use the site better. It's similar to
the HTTP/1.0 or 1.1, keep-alive and pipelining that you can enable in
your browser. Most users won't play with it, still that's pretty
configurable. Similarly end users can decide to enable/disable IPv6 or
IDN.

> course, if this happens then end-users would be happier :)

I think you got it :-)

Willy

---

From: Dave Cridland <[email-masked]>
Date: Wed, 27 Jul 2011 18:07:12 +0100

> what mechanism you're talking about.

Happy eyeballs - try everything as soon as you can, in parallel. Drop  
everything else when one does.

Dave.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 09:09:38 +1000

> everything else when one does.

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 (I
use 1/2 the original timeout, but that is a implementation detail).
You continue to use the address that works for that session.  You
drop any other connections to other addresses that complete.

You get fast failover without lots of extra connection attempts
with the advantage that you detect and recover from network failures
that only affect the client.

Mark

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jul 2011 01:50:39 +0200 (MEST)

Mark Andrews wrote:
> Dave Cridland writes:

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.

While this might currently "improve" the end user experience
of clients, it simultaneously adds a deterrant to server operators
to announce IPv6 addresses (even multiple IP addresses -- they're
better of with IPv4 NAT if they have multiple servers at a single
location).

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 12:01:18 +1000

In message <[email-masked]>, Martin Rex writes
> 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.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 27 Jul 2011 19:13:34 +0200

> everything else when one does.

This sensibly increases load on servers with useless connections, and
is counter-efficient in mobile networks where sending uplink packets
is the limiting factor !

Willy

---

From: Martin Rex <[email-masked]>
Date: Fri, 29 Jul 2011 04:38:12 +0200 (MEST)

Mark Andrews wrote:
> Martin Rex writes:
> > > more that 2 address you do something similar for the next one
> > 

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!

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Jul 2011 13:04:33 +1000

In message <[email-masked]>, Martin Rex writes
> > 60 or 90 seconds by doing the attempts serially.

Yes, that small.  For most people, most connections are "in country"
or "in continent" however there are always exceptions to this.
The times are driven by human delay tolerances.

> in non-congested(!) situations. 

Indeed.  However only one will have data sent over it.  The three
way handshake won't even complete for two of them in many cases.
For those that do complete the server won't be woken up in many
cases as no data gets sent.

> So your approach is already hurting the network without congestion!

Only if you think a could of extra TCP connection attemps to servers
on the other side of the world is hurting the network. 
 
B.T.W. I'm well aware of speed of light issues.  Look at my signature.

Mark

---

From: Philip Homburg <[email-masked]>
Date: Fri, 29 Jul 2011 09:55:16 +0200

>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.