Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Doesn't a WEBSOCKET client required a backend WEBSOCKET server to do handshaking and authentication to even allow it in the first so? If so, whose network management constraint is it bypassing? Roy T. Fielding wrote: I sent this originally in March, before the last call, but I see that it still applies for draft-ietf-hybi-thewebsocketprotocol-13. If draft-ietf-hybi-thewebsocketprotocol-13 is approved, please add an IESG note to the effect of: = The WebSocket protocol is designed with an assumption that TCP port 80 or 443 will be used for the sake of tunneling raw socket exchanges over HTTP. The result is a convoluted and inefficient exchange of hashed data for the sake of bypassing intermediaries that may be routing, authenticating, filtering, or verifying traffic on those ports. The sole reason for using ports 80 and 443, and hence requiring the hashed data exchange, is because many organizations use TCP port blocking at firewalls to prevent unexpected network traffic, but allow the HTTP ports to remain open because they are expected to be used for normal Web request traffic. WebSocket deliberately bypasses network management constraints in order to enable Web application developers to send arbitrary data though a trusted port. Naturally, the WebSocket protocol does not have the same network characteristics as HTTP. The messages exchanged are likely to be smaller, more interactive, and delivered asynchronously over a long-lived connection. Unfortunately, those are the same characteristics of typical denial-of-service attacks over HTTP. Organizations deploying WebSockets should be aware that existing network equipment or software monitoring on those ports may need to be updated or replaced. = Cheers, Roy T. Fielding http://roy.gbiv.com/ Begin forwarded message: From: Roy T. Fielding field...@gbiv.com Date: March 29, 2011 5:23:33 AM PDT To: Server-Initiated HTTP h...@ietf.org Cc: i...@iesg.org Subject: reuse of port 80/443 in hybi I am finding it difficult to participate in hybi in any meaningful way due to the very poor assumption that websockets traffic should use the same ports as Web traffic. Apparently, this decision was made on the basis of hums at an in-person WG meeting and the chairs believe it to be consensus (and thus quash any discussion that has apparent consensus due to the extent to which people keep bringing up old issues). It might even make some sense, given the name of this working group. Unfortunately, it is a fatal error. The rest of the protocol discussion is predicated on it, and enormously complex, for the sole reason of that initial error in design. More the pity. It assumes that the network infrastructure that currently monitors and balances traffic over 80/443 is going to instantly adapt to TCP-over-HTTP, as opposed to treating it like a denial of service attack. Browsers are fully capable of opening up new ports in firewalls simply by concerted use of open standards. Many other applications do so without this painful corruption of existing protocols. Yes, it takes time (but not as much time as one would think). Yes, there will be some companies that forcibly block some ports, just like there are some companies that forcibly block HTTP sites like facebook.com. That is their right. If the protocol is safe to use, it will be deployable over time. If not, then it shouldn't make the Web situation worse by increasing the amount of packet filtering at firewalls. So, I don't think the hybi work is worth continuing. The rest of the protocol decisions simply don't matter -- any of the already deployed proprietary hacks are better by default because they are no worse than hybi and don't have the imprimatur of the IETF. I'd rather develop a protocol that works with network administration rather than against it. I only ask that an IESG note be added to the final specification to the effect that this protocol knowingly misuses the Internet for the sake of bypassing organizational security. Be honest and let the admins make their own decisions. Cheers, Roy T. Fielding http://roy.gbiv.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/9/2 Hector sant9...@gmail.com: Doesn't a WEBSOCKET client required a backend WEBSOCKET server to do handshaking and authentication to even allow it in the first so? If so, whose network management constraint is it bypassing? I suppose Roy talks about company firewalls or HTTP proxies inspecting HTTP traffic nature. -- Iñaki Baz Castillo i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
I sent this originally in March, before the last call, but I see that it still applies for draft-ietf-hybi-thewebsocketprotocol-13. If draft-ietf-hybi-thewebsocketprotocol-13 is approved, please add an IESG note to the effect of: = The WebSocket protocol is designed with an assumption that TCP port 80 or 443 will be used for the sake of tunneling raw socket exchanges over HTTP. The result is a convoluted and inefficient exchange of hashed data for the sake of bypassing intermediaries that may be routing, authenticating, filtering, or verifying traffic on those ports. The sole reason for using ports 80 and 443, and hence requiring the hashed data exchange, is because many organizations use TCP port blocking at firewalls to prevent unexpected network traffic, but allow the HTTP ports to remain open because they are expected to be used for normal Web request traffic. WebSocket deliberately bypasses network management constraints in order to enable Web application developers to send arbitrary data though a trusted port. Naturally, the WebSocket protocol does not have the same network characteristics as HTTP. The messages exchanged are likely to be smaller, more interactive, and delivered asynchronously over a long-lived connection. Unfortunately, those are the same characteristics of typical denial-of-service attacks over HTTP. Organizations deploying WebSockets should be aware that existing network equipment or software monitoring on those ports may need to be updated or replaced. = Cheers, Roy T. Fielding http://roy.gbiv.com/ Begin forwarded message: From: Roy T. Fielding field...@gbiv.com Date: March 29, 2011 5:23:33 AM PDT To: Server-Initiated HTTP h...@ietf.org Cc: i...@iesg.org Subject: reuse of port 80/443 in hybi I am finding it difficult to participate in hybi in any meaningful way due to the very poor assumption that websockets traffic should use the same ports as Web traffic. Apparently, this decision was made on the basis of hums at an in-person WG meeting and the chairs believe it to be consensus (and thus quash any discussion that has apparent consensus due to the extent to which people keep bringing up old issues). It might even make some sense, given the name of this working group. Unfortunately, it is a fatal error. The rest of the protocol discussion is predicated on it, and enormously complex, for the sole reason of that initial error in design. More the pity. It assumes that the network infrastructure that currently monitors and balances traffic over 80/443 is going to instantly adapt to TCP-over-HTTP, as opposed to treating it like a denial of service attack. Browsers are fully capable of opening up new ports in firewalls simply by concerted use of open standards. Many other applications do so without this painful corruption of existing protocols. Yes, it takes time (but not as much time as one would think). Yes, there will be some companies that forcibly block some ports, just like there are some companies that forcibly block HTTP sites like facebook.com. That is their right. If the protocol is safe to use, it will be deployable over time. If not, then it shouldn't make the Web situation worse by increasing the amount of packet filtering at firewalls. So, I don't think the hybi work is worth continuing. The rest of the protocol decisions simply don't matter -- any of the already deployed proprietary hacks are better by default because they are no worse than hybi and don't have the imprimatur of the IETF. I'd rather develop a protocol that works with network administration rather than against it. I only ask that an IESG note be added to the final specification to the effect that this protocol knowingly misuses the Internet for the sake of bypassing organizational security. Be honest and let the admins make their own decisions. Cheers, Roy T. Fielding http://roy.gbiv.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Wed, Jul 27, 2011 at 06:07:12PM +0100, Dave Cridland wrote: On Wed Jul 27 06:25:49 2011, Willy Tarreau wrote: On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote: SRV provides load-balancing and failover. I never said that SRV is a 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. 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. Happy eyeballs - try everything as soon as you can, in parallel. Drop 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Wed Jul 27 02:28:06 2011, Mark Andrews wrote: Billions of dollars have been wasted globally for the sake of a few hours 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. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Hi Iñaki, On Tue, Jul 26, 2011 at 11:58:41AM +0200, Iñaki Baz Castillo wrote: 2011/7/24 Willy Tarreau w...@1wt.eu: 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. But I don't understand how a client is supposed to decide by himself 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 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). I'd say that the common practice with DNS has always been to use A records for IPv4, 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/ and this would be transparent to the upper application layers. BTW: I know that any web browser would first lookup at the /etc/hosts 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/ 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 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote: SRV provides load-balancing and failover. I never said that SRV is a 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. 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. Billions of dollars have been wasted globally for the sake of a few hours work by webbrowser vendors. This analysis seems a bit simplified in my opinion. Nothing is completely white or black. Regards, Willy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/26 Willy Tarreau w...@1wt.eu: 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 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 presented till now. 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Wed, Jul 27, 2011 at 11:43:58AM +0200, Iñaki Baz Castillo wrote: 2011/7/26 Willy Tarreau w...@1wt.eu: 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 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). 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. - 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). 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. I'm pretty sure that can be done, but clearly not the way it's been presented till now. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/27 Willy Tarreau w...@1wt.eu: That's where I think you're mistaken. As long as you think of it as mandatory 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/, 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Wed, Jul 27, 2011 at 12:46:28PM +0200, Iñaki Baz Castillo wrote: 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 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 So assuming that SRV is optional for clients, the provider does not 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 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. 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. 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. 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. 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). 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 even worse. That's why SRV cannot be made mandatory. 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/, 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/27 Willy Tarreau w...@1wt.eu: 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. 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Wed, Jul 27, 2011 at 03:45:38PM +0200, Iñaki Baz Castillo wrote: 2011/7/27 Willy Tarreau w...@1wt.eu: 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. 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? Users in front of web browsers. 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. 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/. 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 are no more than 10? 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/27 Willy Tarreau w...@1wt.eu: 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. 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/. 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 are no more than 10? 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. 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Wed, Jul 27, 2011 at 05:19:30PM +0200, Iñaki Baz Castillo wrote: 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. 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. 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 think you got it :-) Willy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Wed Jul 27 06:25:49 2011, Willy Tarreau wrote: On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote: SRV provides load-balancing and failover. I never said that SRV is a 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. 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. Happy eyeballs - try everything as soon as you can, in parallel. Drop everything else when one does. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message 9031.1311786432.357811@puncture, Dave Cridland writes: On Wed Jul 27 06:25:49 2011, Willy Tarreau wrote: On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote: SRV provides load-balancing and failover. I never said that SRV is a 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. 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. Happy eyeballs - try everything as soon as you can, in parallel. Drop 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/24 Willy Tarreau w...@1wt.eu: 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. 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). 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. I consider that a hack. 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. SRV provides load-balancing and failover. I never said that SRV is a solution for temporaly put in maintenance a server. 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. 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/24 Willy Tarreau w...@1wt.eu: 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. 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/ 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/25 Keith Moore mo...@network-heretics.com: 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/25 Mark Andrews ma...@isc.org: 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. Great explanation. -- Iñaki Baz Castillo i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message CALiegf=e48kkf+gky1my7lippub-0kzdgsgzrjxk1azupag...@mail.gmail.com , =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= writes: 2011/7/24 Willy Tarreau w...@1wt.eu: 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. 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). 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. I consider that a hack. 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. SRV provides load-balancing and failover. I never said that SRV is a 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. 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. 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 8:46 PM, Mark Andrews ma...@isc.org wrote: Adding a SRV lookup should add 0ms if it isn't there as you should be making A, and SRV lookups in parallel. Non-existance is as cachable as existance is. But you have to wait until the SRV returns even if the A/ 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. -- John A. Tamplin Software Engineer (GWT), Google ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Mon, Jul 25, 2011 at 10:46:58AM +1000, Mark Andrews wrote: Adding a SRV lookup should add 0ms if it isn't there as you should be making A, 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 : $ host -t srv _xmpp-server._tcp.gmail.com _xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server1.l.google.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-server2.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-server4.l.google.com. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Mon, Jul 25, 2011 at 02:50:37PM +1000, Mark Andrews wrote: In message 20110725042921.gj22...@1wt.eu, Willy Tarreau writes: On Mon, Jul 25, 2011 at 10:46:58AM +1000, Mark Andrews wrote: Adding a SRV lookup should add 0ms if it isn't there as you should be making A, 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. Ah OK : if it isn't there. Sorry for missing it. Willy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 03:49:33PM -1000, David Conrad wrote: [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. 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. 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. 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. On Jul 24, 2011, at 9:29 AM, Willy Tarreau wrote: DNS provides geolocation and proposes you the closest working datacenter. 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'. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Mon, Jul 25, 2011 at 11:12:46AM +1000, Mark Andrews wrote: 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 But the Smart Relay host uses MX records. The Smart Relay host should 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message 20110725045821.gn22...@1wt.eu, Willy Tarreau writes: On Sun, Jul 24, 2011 at 03:49:33PM -1000, David Conrad wrote: [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. 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. 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. 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. 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 On Jul 24, 2011, at 9:29 AM, Willy Tarreau wrote: DNS provides geolocation and proposes you the closest working datacenter. 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 ser ver 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Willy Tarreau wrote: 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. 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 the objects. I've observed it. won't happen. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message b2c17b21-ea8a-4698-8c41-f55a9aa14...@gbiv.com, Roy T. Fielding writes: On Jul 21, 2011, at 10:52 AM, I=F1aki Baz Castillo wrote: 2011/7/21 Dave Cridland d...@cridland.net: 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 am tired of this. SRV is not used for HTTP because SRV adds latency 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 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 WebSocket= s. If you want SRV to be part of the proposed standard, then you have to convi= nce 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Fri Jul 22 06:43:45 2011, Willy Tarreau wrote: 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 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. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Dave Cridland wrote: 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. In my capacity of a WG participant: +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Masataka Ohta wrote: Dave Cridland wrote: Where is a proof? Sorry, I've a habit of using the word proof in the English 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Jul 24, 2011, at 4:42 AM, Iñaki Baz Castillo wrote: 2011/7/23 Roy T. Fielding field...@gbiv.com: 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 am tired of this. SRV is not used for HTTP because SRV adds latency to the initial request for no useful purpose whatsoever. 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. SRV records for XMPP and MX records for mail are useful because there is only one such 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 manner in which there are often several HTTP servers per machine (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 even more anarchic than HTTP -- it will have to be, given that the sane network admins will block it by default. 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). *shrug* 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Jul 24, 2011, at 12:33 AM, Mark Andrews wrote: In message b2c17b21-ea8a-4698-8c41-f55a9aa14...@gbiv.com, Roy T. Fielding writes: On Jul 21, 2011, at 10:52 AM, I=F1aki Baz Castillo wrote: 2011/7/21 Dave Cridland d...@cridland.net: 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 am tired of this. SRV is not used for HTTP because SRV adds latency 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
* Iñaki Baz Castillo wrote: Open the fastest web page and tell me how long it takes. Too long. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · 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/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
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 j...@google.com: ~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. INSRV ;; 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 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. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
[ should we leave ietf@ietf.org in CC or not ? I'm suspecting that people who read this address will quickly get bored by hybi traffic ] On Sun, Jul 24, 2011 at 10:35:45AM +0100, Dave Cridland wrote: 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 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. 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. That's clearly what I understood. 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. 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/ or CNAME and that SRV is used for failover. If we say MUST, sites won't bother emitting correct addresses in A/ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Hi Mark, On Sun, Jul 24, 2011 at 05:33:23PM +1000, Mark Andrews wrote: In message b2c17b21-ea8a-4698-8c41-f55a9aa14...@gbiv.com, Roy T. Fielding writes: On Jul 21, 2011, at 10:52 AM, I=F1aki Baz Castillo wrote: 2011/7/21 Dave Cridland d...@cridland.net: 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 am tired of this. SRV is not used for HTTP because SRV adds latency 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 01:26:53PM +0200, Iñaki Baz Castillo wrote: 2011/7/22 Willy Tarreau w...@1wt.eu: 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. 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. 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. 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 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/ 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. Having multiple A/ 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/ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 01:47:36PM +0200, Iñaki Baz Castillo wrote: 2011/7/24 Willy Tarreau w...@1wt.eu: 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. 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/ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 01:42:26PM +0200, Iñaki Baz Castillo wrote: 2011/7/23 Roy T. Fielding field...@gbiv.com: 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 am tired of this. SRV is not used for HTTP because SRV adds latency to the initial request for no useful purpose whatsoever. 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). 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. 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,). Could you explain me why DNS A is good but DNS SRV is bad in such anarchic deployments? 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 7:11 AM, Iñaki Baz Castillo i...@aliax.net wrote: 2011/7/22 David Endicott dendic...@gmail.com: 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? -- John A. Tamplin Software Engineer (GWT), Google ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 08:25:05PM +0200, Iñaki Baz Castillo wrote: 2011/7/24 Willy Tarreau w...@1wt.eu: Making an additional DNS request and a connection come with a cost. 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/ 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 08:24:25PM +0200, Iñaki Baz Castillo wrote: Yes it has. Either you open a fresh new connection, or you reuse an 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 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. 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. 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 :-) 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. Having multiple A/ 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/ 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. 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. However, please read what I've explained in another mail about the limitations of client-based failover in web environments. 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
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 08:28:49PM +0200, Iñaki Baz Castillo wrote: 2011/7/24 Willy Tarreau w...@1wt.eu: 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). 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. 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. Could you explain me why DNS A is good but DNS SRV is bad in such anarchic deployments? DNS is not mandatory for HTTP. It's not DNS A which makes it good, but no mandatory DNS. This is a huge difference. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 08:30:11PM +0200, Iñaki Baz Castillo wrote: 2011/7/24 John Tamplin j...@google.com: ~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. Regards, Willy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 08:57:45PM +0200, Iñaki Baz Castillo wrote: 2011/7/24 Willy Tarreau w...@1wt.eu: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 09:02:59PM +0200, Iñaki Baz Castillo wrote: 2011/7/24 Willy Tarreau w...@1wt.eu: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Sun, Jul 24, 2011 at 09:18:40PM +0100, Dave Cridland wrote: 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. 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. 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. 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 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. 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. 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 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). 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Hector Santos wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Willy Tarreau 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. How long does it take to fetch all the contents of 100 or 200 objects? 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. It's merely additional 100ms. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Willy Tarreau wrote: On lossy networks such as 3G, they definitely are. A lost UDP packet is not retransmitted nor signaled as lost, so the browser has to retry. However, once the connection is established to the server, most losses are more or less smoothed by TCP extensions such as SACK. So yes, it can take several seconds to just resolve a host and then only a few hundreds of ms to retrieve the objects. I've observed it. Poor implementation. If the network between a mobile phone and its name server is known to be lossy and latency is the issue, send multiple queries to the name server. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Willy Tarreau wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message 20110724183343.gy22...@1wt.eu, Willy Tarreau writes: On Sun, Jul 24, 2011 at 08:25:05PM +0200, I=F1aki Baz Castillo wrote: 2011/7/24 Willy Tarreau w...@1wt.eu: Making an additional DNS request and a connection come with a cost. 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/ request for 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. = 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. 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, and SRV lookups in parallel. Non-existance is as cachable as existance is. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message 20110724193230.ge22...@1wt.eu, Willy Tarreau writes: On Sun, Jul 24, 2011 at 09:02:59PM +0200, I=F1aki Baz Castillo wrote: 2011/7/24 Willy Tarreau w...@1wt.eu: 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. = 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 But the Smart Relay host uses MX records. The Smart Relay host should be seen as the same as a HTTP proxy. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
[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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Jul 24, 2011, at 3:33 AM, Mark Andrews wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message CABLsOLD-KM6DnR8HvfGH8N1M=1bz4z8zus0ydczaxsfocbq...@mail.gmail.com , John Tamplin writes: On Sun, Jul 24, 2011 at 8:46 PM, Mark Andrews ma...@isc.org wrote: Adding a SRV lookup should add 0ms if it isn't there as you should be making A, and SRV lookups in parallel. Non-existance is as cachable as existance is. But you have to wait until the SRV returns even if the A/ 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.% of cases the three answers will come in within 1ms of each other and you may be waiting on the A or record. It really doesn't take any longer to answer a SRV query compared to a A or query. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message 4b3c19fd-b736-4da7-9db5-3d433320d...@network-heretics.com, Keith M oore writes: On Jul 24, 2011, at 3:33 AM, Mark Andrews wrote: 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. 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. 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Jul 24, 2011, at 11:21 PM, Mark Andrews wrote: 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. 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message 3bc48562-6459-4fb9-9806-731af87fe...@network-heretics.com, Keith M oore writes: On Jul 24, 2011, at 11:21 PM, Mark Andrews wrote: 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. =20 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 =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 NAPTR is not defined for HTTP. SRV is not defined for HTTP. =20 The problem never went away, but the DNS-based solutions were defined = a =3D long time ago and never used. =20 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. _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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message 20110725042921.gj22...@1wt.eu, Willy Tarreau writes: On Mon, Jul 25, 2011 at 10:46:58AM +1000, Mark Andrews wrote: Adding a SRV lookup should add 0ms if it isn't there as you should be making A, 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Thu, Jul 21, 2011 at 9:57 PM, David Endicott dendic...@gmail.com wrote: 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. 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.) 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. 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. 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
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
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 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 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. On Thu, Jul 21, 2011 at 1:52 PM, Iñaki Baz Castillo i...@aliax.net mailto:i...@aliax.net wrote: 2011/7/21 Dave Cridland d...@cridland.net mailto:d...@cridland.net: 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 i...@aliax.net mailto:i...@aliax.net ___ hybi mailing list h...@ietf.org https://www.ietf.org/mailman/listinfo/hybi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Hi Dave, On Thu, Jul 21, 2011 at 10:52:07PM +0100, Dave Cridland wrote: On Thu Jul 21 18:33:38 2011, Willy Tarreau wrote: 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... If SRV (with a fallback) is defined as part of the core spec, this usage would use the fallback. Which would be indicated by which component since the DNS is down ? 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. Okay, a thought experiment for you. Let's assume we go ahead with dumb A/ lookups. How will it be possible for a server to later inform browser it wishes to use SRV lookups? The same way it has been stated that browsers should use 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. If you have an answer for this, we can make it optional, and moreover 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/21 David Endicott dendic...@gmail.com: 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. 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: http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02 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 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/22 Bruce Atherton br...@callenish.com: 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 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.COMfor WS URI b) _wss._tcp.DOMAIN.COM for WSS URI Regards. -- Iñaki Baz Castillo i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/21 David Endicott dendic...@gmail.com: 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) David, this does not make sense at all. Let see this case: a) mailto:al...@google.com b) xmpp:al...@google.com 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/ is done, but in other cases we all do know that other kind of DNS queries are done. -- Iñaki Baz Castillo i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/22 Willy Tarreau w...@1wt.eu: 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. 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 21/07/2011 3:21 PM, Dave Cridland wrote: 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. 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. 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. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
[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. -Original Message- From: hybi-boun...@ietf.org [mailto:hybi-boun...@ietf.org] 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 On 21/07/2011 3:21 PM, Dave Cridland wrote: 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. 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. 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. 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. ___ hybi mailing list h...@ietf.org https://www.ietf.org/mailman/listinfo/hybi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Thu, Jul 21, 2011 at 7:47 PM, Bruce Atherton br...@callenish.com 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. 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. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Thu, Jul 21, 2011 at 10:24 PM, David Endicott dendic...@gmail.com wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Fri, Jul 22, 2011 at 01:22:15AM +0200, Iñaki Baz Castillo wrote: 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.COMfor WS URI 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/ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Good to know, thank you. On Fri, Jul 22, 2011 at 5:55 AM, Dave Cridland d...@cridland.net wrote: 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. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/**byowner/user/dwd/bookmarks/http://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
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. Good to know, thank you. ActuallyI 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? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Fri, Jul 22, 2011 at 9:47 AM, David Endicott dendic...@gmail.com wrote: ActuallyI 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. 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 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: _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. 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 Do browsers restrict origin / cross-site access based on name or on address? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message 4e28a51f.4020...@callenish.com, Bruce Atherton writes: 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. No. MUST is what is needed. It's a new protocol. Do what's best from day one. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Jul 23, 2011, at 5:23 PM, Mark Andrews wrote: In message 4e28a51f.4020...@callenish.com, Bruce Atherton writes: 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. No. MUST is what is needed. It's a new protocol. Do what's best from day one. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Fri Jul 22 01:11:33 2011, Masataka Ohta wrote: Dave Cridland wrote: It's proven impossible, despite effort, to retrofit SRV onto HTTP; Where is a proof? 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. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
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. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SRV and http(s) (was Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard)
Mark Andrews wrote: 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. CONNECT server.example.org:100 HTTP/1.1 Host: www.example.com 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Dave Cridland wrote: Where is a proof? Sorry, I've a habit of using the word proof in the English 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Fri, Jul 22, 2011 at 07:34:49PM +0900, Masataka Ohta wrote: Dave Cridland wrote: Where is a proof? Sorry, I've a habit of using the word proof in the English 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. That's a perfect proof against IPv6 deployment. Infrastructure won't be updated. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
In message 9031.1311328268.180517@puncture, Dave Cridland writes: On Fri Jul 22 01:11:33 2011, Masataka Ohta wrote: Dave Cridland wrote: It's proven impossible, despite effort, to retrofit SRV onto HTTP; Where is a proof? 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. 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. 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. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
Scott Schmit wrote: _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. 2001:db8::2 I.e., content providers could control/measure their probability of 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Fri, Jul 22, 2011 at 11:36:10PM +0900, Masataka Ohta wrote: Scott Schmit wrote: _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. 2001:db8::2 I.e., content providers could control/measure their probability of 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? 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Jul 21, 2011, at 10:52 AM, Iñaki Baz Castillo wrote: 2011/7/21 Dave Cridland d...@cridland.net: 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 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Jul 22, 2011, at 4:51 AM, Dave Cridland wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
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. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
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. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
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. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/19 Dave Cridland d...@cridland.net: 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. 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
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. On Wed, Jul 20, 2011 at 5:12 PM, Iñaki Baz Castillo i...@aliax.net wrote: 2011/7/19 Dave Cridland d...@cridland.net: 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. 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 i...@aliax.net ___ hybi mailing list h...@ietf.org https://www.ietf.org/mailman/listinfo/hybi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/21 David Endicott dendic...@gmail.com: 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. 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/ 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 i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On Thu, Jul 21, 2011 at 06:27:49PM +0200, Iñaki Baz Castillo wrote: 2011/7/21 David Endicott dendic...@gmail.com: 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. 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/ 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, 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/21 Willy Tarreau w...@1wt.eu: 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. Host files just replace A/ resolution. Still is possible to query SRV records and later perform hostfiles check for retrieved hostnames (instead of performing DNS A/ for them). 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. 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 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. 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). 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. 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. 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. 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/ resolution for locating a WS server. Regards. -- Iñaki Baz Castillo i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
