Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon <mellon@fugue.com> Wed, 16 August 2017 13:37 UTC

Return-Path: <mellon@fugue.com>
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 0D8551320D9 for <homenet@ietfa.amsl.com>; Wed, 16 Aug 2017 06:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 glPF8L1twwve for <homenet@ietfa.amsl.com>; Wed, 16 Aug 2017 06:37:21 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2FF13201E for <homenet@ietf.org>; Wed, 16 Aug 2017 06:37:20 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id o124so11515304qke.3 for <homenet@ietf.org>; Wed, 16 Aug 2017 06:37:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RUwsglaYW+jRU/YAoshaUjcnzMvExvmPJneHrD1YHjg=; b=p+Ni9hojsRVVvp1O6XE+W6RXtZEFOCYJmj1Zoh1RTMqkM2H37crLfVA0+EHZy79B6f 6dewNK4voq/5ZaPhczBD5mZ+LMHOEX+t7Ag+62XxjvDS/OtOgpTL8GC4K64xcvOHTZiT +w22gq2AOTZKB+yayvtZl1zuXNrCXew3FTumjNZ700tJioFCi4UCiahrEW7d05cwWbsQ scx1vCQeWzoh1pcUK5uRQ5QY7Dk/4QjfcDh1JjjhDnqQujOdear6cc6gcbvfIXRTvF2B LSAr71Qyyjz4b3O5ull5uLl4P/1W6v9Q9F59q1UGo3g9XBb/4i1UwQQpzX3UsIc54dMu N/7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RUwsglaYW+jRU/YAoshaUjcnzMvExvmPJneHrD1YHjg=; b=L0Kh7vuyLCOS8uy+B+T6rlt/72vUQOl04jdFPBwEitkXsh5Zzvy+lHu7tmOshKVc+F 1aURIrYVIXUkg9qMULcbs0R/VkFVirYdNMr6wWJim0Zr9X7tdbcggnhLlEWQ+W2EzKCK E/ey95kbf+kjaUunhJr/NEj+ApwxbYATNDQg4Nsp7PRAAcq2rQSeHfBDN0TGMPAMylKu ipRvhhK1IPQ2DwvYx1iA5RnIMP20kIr/A2xb1ZHyT3vWpVUHnfXDfGs8tXc2xnDWvU5l zojD4qs1Cm9Q2qJmF2N1COixfSgIgXH4ZZ4ibi0w13EpPY0Y0TKQc/ZQibzQYNP5C4I7 JjFQ==
X-Gm-Message-State: AHYfb5hQpAJ3HnNympncWHCQj9SQIX0U9kh790jI+H0DUt51yl+SMrUf MzonWBDTYMWy2OV+
X-Received: by 10.55.215.28 with SMTP id m28mr2264362qki.318.1502890639860; Wed, 16 Aug 2017 06:37:19 -0700 (PDT)
Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id q19sm587998qta.2.2017.08.16.06.37.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 06:37:19 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <769C4508-BB58-4BCB-A3CE-3657FB43A8AA@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EE2D7AA2-87E5-42D6-AFC6-8201F346D6F4"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 16 Aug 2017 09:37:17 -0400
In-Reply-To: <871soby776.fsf@toke.dk>
Cc: Juliusz Chroboczek <jch@irif.fr>, HOMENET <homenet@ietf.org>
To: Toke Høiland-Jørgensen <toke@toke.dk>
References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.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> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <E3E75086-BF36-4F59-86BD-7FFDAFE772AB@fugue.com> <87fuctxdrc.fsf@toke.dk> <FB44A942-9DE3-4CE6-88C5-402B20756462@fugue.com> <877ey4y62g.fsf@toke.dk> <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com> <874lt8xv9j.fsf@toke.dk> <3DE50D7C-53BF-4758-8DED-A2CA89C8ABE7@fugue.com> <871soby776.fsf@toke.dk>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/zOhqrix2452Um9ijxAsishSZGT4>
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: Wed, 16 Aug 2017 13:37:23 -0000

El 16 ag 2017, a les 9:26, Toke Høiland-Jørgensen <toke@toke.dk> va escriure:
> Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> writes:
> 
>> El 15 ag 2017, a les 19:32, Toke Høiland-Jørgensen <toke@toke.dk> va escriure:
>>>> In both of these cases, you are better off doing what we discussed
>>>> earlier and setting up your own DNS cache, possibly with a whitelist
>>>> for domains you want to send to the ISP forwarder.
>>> 
>>> Sure, and that's what I usually do. But if we can't specify that
>>> behaviour for homenet, at least trying all upstream DNS servers gives a
>>> better chance of finding one that works.
>> 
>> I'm really sorry, but I'm actually having trouble contextualizing the
>> failure mode that you are talking about here.   Didn't I agree with
>> you in a previous message that we should try all the upstream DNS
>> servers?
> 
> Hmm, right, I guess you did. My point was more that an MPvD-aware client
> that only uses on PvD may experience worse performance than one that
> uses the in-home resolver. But I guess the client should be smart
> enough to deal with that?

I think this is a real edge case.   You have two connections, the DNS server on one of them is broken, the DNS server on the other is not, but the second connection performs so much worse than the first that you'd rather use an answer from the DNS server on the second to contact a service on the first.

If you were in an engineering staff meeting trying to justify adding extra code to do this, what would you have to say to get the group to agree to do the work?   What would that code look like?

Sometimes things are just broken.   Expecting a homenet router to solve every possible configuration screwup on the part of the ISP isn't realistic.   As customers of these ISPs, we expect them to do a decent job, and if an ISP fails often enough to make this code worth writing, they probably need to be in a different business.

>>> You may be right that hacking up a working prototype isn't that hard.
>>> But the failure modes change from "the internet is down" or may "I
>>> cannot access site A", to "site A is working every third attempt, except
>>> it is entirely broken on device X" maybe even with an added "ah, but
>>> it works on device X if I go into the kitchen".
>> 
>> Didn't we agree that we aren't round-robining?
> 
> Yeah, but I was referring to the failure mode for MPvD vs non-MPvD
> clients. I.e. if one of the resolvers fails for whatever reason, only
> MPvD-aware clients that happen to select that PvD will notice; whereas
> if there's only one resolver it will be very obvious when it's not
> working...

That's not how PvDs work.   You don't select one and only use that.   You try both.

>>> Hmm, while writing this is occurred to me that it might make sense to
>>> just export the ISP DNS server(s) directly in the MPvD-only RAs?
>> 
>> This would certainly work, but now you can't have your nice local
>> resolver that does what you want.   However, I think you are right
>> that this is the right default behavior for MPvD-aware devices.
> 
> I would keep the in-home resolver for clients that do not support MPvD;
> and probably also announce it as a separate PvD for MPvD-aware clients?
> 
> Also, I think I would prefer running a single resolver in the home,
> rather than running one on every router.

I think there's some text in the document that was put in before I did the dnssd discovery relay stuff and hasn't been updated since.   There does need to be a dnssd discovery relay running on every router.   And if the dnssd registration protocol is running over unicast, then we need some kind of relay on port 53 on every router, so that we can tell that the device that's doing the registration is on the local link.   If we do the registration through the discovery relay, this isn't necessary.   I don't remember how Stuart specified this, so I'm not sure.

But the motivation for doing this is not that every router has to have a caching recursive resolver running on it.