Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA
Toke Høiland-Jørgensen <toke@toke.dk> Sun, 13 August 2017 15:49 UTC
Return-Path: <toke@toke.dk>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A936C132682 for <homenet@ietfa.amsl.com>; Sun, 13 Aug 2017 08:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72xxxMsgHn5w for <homenet@ietfa.amsl.com>; Sun, 13 Aug 2017 08:49:24 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757DE132395 for <homenet@ietf.org>; Sun, 13 Aug 2017 08:49:23 -0700 (PDT)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502639356; bh=8l7Q5ZWfuspHNekpThcIInsb1sLyYEav6cYcHwQ8qFA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LHEZfz5z7ws7bXms2MeO32tHBUTeU4tyJWrYSkbaXaSy/QPl/ZSKFvWH/7W2xBf6y k7+kSot3Z3AY1mxzwa7tn90sF3DbjLg8vy2N3EdHfP9RY2aqLM/GAvGS552jZ+Zb+D ondJqziqUWJBvjZ4KZ21A9Afz2MbGI/jNajliOM97W4WGQJJXX3kLJ+PIgvv9+cQrQ nRbO3GQT/QVisatQ87OE+Man8LDc7Ou4kL4GmVM/8fIB2i22GVNobPOKHOoGLxtq30 2Q0MThI+4T7BxPePIhfIk2EKzH8/lyd3lcNU2m+gaIxACFDsCt+odmLckOJOpa2V/n Rb0iyTfcA2PGg==
To: Ted Lemon <mellon@fugue.com>
Cc: Juliusz Chroboczek <jch@irif.fr>, HOMENET <homenet@ietf.org>
In-Reply-To: <FCAD81FA-BBA0-45B0-8F1F-D1D5FD010484@fugue.com>
References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <A9C8CA05-54A0-4160-B2F0-645744BD259E@fugue.com> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <CAPt1N1m+218+FX_G+2W-msDWmxP8XXMKF9S0faTeCBnEEzk1uw@mail.gmail.com> <877eyaz2jm.fsf@toke.dk> <CAPt1N1m5nVGD-y2VrbkoTEPTs4qF98oRxGuvd-Has1yzuS0fmg@mail.gmail.com> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <CAPt1N1=oiU+DbjD6izOBNJOnC25d=-S3ARqFxydRfWLEet5mEQ@mail.gmail.com> <87valry4o7.fsf@toke.dk> <FCAD81FA-BBA0-45B0-8F1F-D1D5FD010484@fugue.com>
Date: Sun, 13 Aug 2017 17:49:18 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87shgvxybl.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/Xz6W7paIssVervxkKGUCVeKfspY>
Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Aug 2017 15:49:26 -0000
Ted Lemon <mellon@fugue.com> writes: >> Perhaps it would help if you could explain (a) the details of "the CDN >> problem" (what mechanism is used to determine answers for a given >> prefix, and what is the failure mode if the wrong address is used?), and >> (b) how the client is supposed to actually work with this mechanism >> (seems to me an unmodified client will probably make a mess of things?). > > The idea with CDNs is that you put the content close to the edge and > give different answers using DNS or HTTP depending on where the client > is. By doing this, you can balance the load across the right number of > servers in the right data centers, and avoid transporting the same > traffic over the backbone many times. Yeah, I am aware of the basic concept of a CDN. What I am (was?) confused about is what it has to do with different DNS answers. I have only ever used Cloudflare, and they use anycast to do their magic (which also seems to me like the obvious way to do it; why are people messing with DNS for this?). Anyhow, consider me educated... :) In any case, the failure mode of getting a it wrong is a sub-optimal path being chosen; but if ISP A's DNS server takes five seconds to respond, we'd get a better result from just using the timely answer from ISP B's and going over the suboptimal path to get to the content (in many cases, at least). >> As for an "ideal" resolver behaviour, to me that would be full recursive >> resolution from the root inside the home, replicating all queries across >> all upstreams and picking the best reply (best being something like >> "first reply that passes DNSSEC validation"). With an "advanced >> configuration" option somewhere that allows the user to override >> arbitrary names/zones as they see fit. > > This is mostly what the MPvD solution does (minus the override option, > which I think is out of scope). Queries are sent to all upstreams, and > the good answer that arrives first is used. What MPvD does _in > addition_ is to make sure that if ISP A's answer is chosen, then ISP > A's connection is used to connect to the destination. But only the client can make that coupling (from DNS reply to connection attempt). So if we're just filtering the result set based on the address the client uses (which is how I interpret what you put in the draft), we're degrading the experience for any client that doesn't know how to repeat the query from another source address. So we'd effectively be requiring hosts to support MPvD; and we're not supposed to require host changes, are we? > For example, if you really, really want to use connection A, then you > only try connection B if you don't have a successful connection > established after 30 seconds, but if you don't care, then you try both > nearly simultaneously and take the first one to succeed to the point > where you have completed the https handshake (for example) and > validated the cert using PKI validation. > > You may also want to configure things so that you have a primary and a > backup connection, and your backup connection is never used for > certain things, or only used for certain things. E.g., if your backup > is a cell phone backup that costs more per megabyte, or has a lower > data cap. Or in some cases just the opposite. This is useful for > situations where you want to be able to have dual-homing for the sake > of IoT six-sigma reliability, but don't want to use the backup link > for anything else, because it's expensive. I can see how these scenarios make sense for a device that know the types of connection (like a cell phone with cellular and WiFi links). Less so in the home, where all the client sees are different prefixes; in this case, either the network has to enforce policy (like the failover scenario), or we'll have to communicate more information to the hosts, which goes back to my point above about host changes... > Now, as for the "mostly" above, the problem with what you've said is > that it doesn't scale: if every home does full recursion, that's a > much larger load on authoritative name servers than currently exists. > There's a reason why that's not how things are done now. If we were to > specify this behaviour, there would be substantial pushback from > dnsop, and I would be participating in that pushback. I don't think > this would get IETF consensus. This is not to say that you are wrong, > but the point is that this is the wrong working group in which to have > that argument. Right, well, I'm not sure I have the energy to go argue with dnsop on this one... :) But I can probably live with a mechanism where we just specify that the user needs to have an option to override the default behaviour (i.e., add their own DNS servers which take precedence over whatever we end up specifying). -Toke
- [homenet] Status of draft-tldm-simple-homenet-nam… STARK, BARBARA H
- Re: [homenet] Status of draft-tldm-simple-homenet… Andrew Sullivan
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Markus Stenberg
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Michael Richardson
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Juliusz Chroboczek
- Re: [homenet] Status of draft-tldm-simple-homenet… Ray Bellis
- Re: [homenet] Status of draft-tldm-simple-homenet… Juliusz Chroboczek
- Re: [homenet] Status of draft-tldm-simple-homenet… Juliusz Chroboczek
- Re: [homenet] Status of draft-tldm-simple-homenet… Ray Bellis
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Juliusz Chroboczek
- Re: [homenet] Status of draft-tldm-simple-homenet… STARK, BARBARA H
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Juliusz Chroboczek
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Michael Richardson
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Tim Chown
- Re: [homenet] Status of draft-tldm-simple-homenet… Michael Richardson
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- [homenet] use of MPvD in homenet Michael Richardson
- Re: [homenet] use of MPvD in homenet Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Juliusz Chroboczek
- Re: [homenet] Status of draft-tldm-simple-homenet… Juliusz Chroboczek
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Ralf Weber
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- Re: [homenet] Status of draft-tldm-simple-homenet… Toke Høiland-Jørgensen
- [homenet] tuscles and conflicting goals / trust w… Michael Richardson
- Re: [homenet] tuscles and conflicting goals / tru… Andrew Sullivan
- Re: [homenet] tuscles and conflicting goals / tru… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Juliusz Chroboczek
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] tuscles and conflicting goals / tru… Michael Richardson
- Re: [homenet] Status of draft-tldm-simple-homenet… Michael Richardson
- Re: [homenet] tuscles and conflicting goals / tru… STARK, BARBARA H
- Re: [homenet] Status of draft-tldm-simple-homenet… Gert Doering
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] Status of draft-tldm-simple-homenet… Juliusz Chroboczek
- Re: [homenet] Status of draft-tldm-simple-homenet… Ted Lemon
- Re: [homenet] tuscles and conflicting goals / tru… Michael Richardson
- Re: [homenet] Status of draft-tldm-simple-homenet… Juliusz Chroboczek