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

Toke Høiland-Jørgensen <toke@toke.dk> Tue, 15 August 2017 11:38 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 D185B132195 for <homenet@ietfa.amsl.com>; Tue, 15 Aug 2017 04:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 t_2TpXPfmvNh for <homenet@ietfa.amsl.com>; Tue, 15 Aug 2017 04:38:03 -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 D18E51320BE for <homenet@ietf.org>; Tue, 15 Aug 2017 04:38:02 -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=1502797075; bh=DLG3RBLht02TeljqxeETeuW05Qi15GELHqU+Nvealhw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XsfhH1bDnMzL1NAn3DFA7PjANbsxvWcYfrihamBmvA1lv7Sx4zoPV8K4lkyxcCdru 9xxxE8fpOTyZRumW7lCj6zQSjCSNCHe/oqDAMuN+8x4takMo9FHPjXxUOVwdzsV3sU 5BNpvKPea1vpuVx1k/0roPebpud8qBCszJeJUPh8maEUkd/JqAIJ4d71YwXDe+3A1d JHNoJ+o3yQ/JIYHD7YHp5MYGzO1zJt4E+y88V0Fo796YCQEzdOTX+VIfw/Q1Ow0ZUp ZHVKrhNEg59K7CM5RAoKfukk6KOHh+SM87mijXafsoJGkTFTlzXmDQsldlketjIXqm M6ya/iEK4G5IQ==
To: Ted Lemon <mellon@fugue.com>
Cc: Juliusz Chroboczek <jch@irif.fr>, HOMENET <homenet@ietf.org>
In-Reply-To: <E3E75086-BF36-4F59-86BD-7FFDAFE772AB@fugue.com>
References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <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> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <E3E75086-BF36-4F59-86BD-7FFDAFE772AB@fugue.com>
Date: Tue, 15 Aug 2017 13:37:59 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87fuctxdrc.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/EI6Qbtbq6WV3DjlWNulXqWeDZ8E>
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: Tue, 15 Aug 2017 11:38:06 -0000

Ted Lemon <mellon@fugue.com> writes:

> El 13 ag 2017, a les 14:25, Toke Høiland-Jørgensen <toke@toke.dk> va escriure:
>>> El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen <toke@toke.dk <mailto:toke@toke.dk>> va escriure:
>>>> 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).
>>> 
>>> Not if the suboptimal path has substantially worse performance for the
>>> duration of the session.
>> 
>> Sure, it depends on the particular application (hence the "in many
>> cases" in my original statement)... My point is just that it's not an
>> obvious across the board win.
>
> Indeed.  However, it is never a lose.

Erm, except when the suboptimal path does *not* have substantially worse
performance for the duration of the session? CDNs are used for other
things than Netflix...

>>> Many hosts we care about already support MPvD because the companies
>>> that sell the software that runs on those hosts think it solves a
>>> useful problem.   Adding support for MPvD on the homenet is a
>>> relatively small change now that their stacks already support it.
>> 
>> Right, so we're adding it as an extra service for hosts that support it?
>> That is fine with me, but then it shouldn't be a requirement. I.e., we
>> can go "supporting MPvD is a good idea, and here is how you do it
>> correctly", rather than the current "must support" language.
>
> If we don't require it, we can assume that it will not be supported.
> It is likely that most hosts will support it,

What are you basing this assessment on?

> so if we don't support it, we are missing an opportunity to make
> things work well on the homenet, not just failing to add a "nice to
> have" feature.

Well, I guess I'm not convinced that MPvD support is really required to
'make things work well'. But, well, if we can limit the complexity cost
I guess that becomes less of a problem.

>>> As for a "degraded experience," do you mean that if we select one
>>> upstream provider for a particular client, that's going to result in a
>>> degraded experience for the user?   Why would that be the case?
>> 
>> I mean that if we query all upstreams we get the best aggregate
>> performance from all available DNS servers. Whereas if we limit queries
>> to a particular ISP, we only get as good performance as that particular
>> ISP can provide. If that was going to be the best on anyway, fine. If
>> not, we are worse off by limiting queries to that ISP.
>
> If one ISP is performing substantially worse than the other, the right
> thing to do is use only the one that's performing well. Neither "doing
> nothing" nor "doing MPvDs" accomplishes this end. However, "doing
> MPvDs" arguably comes closer.

Depending on the type of performance problem. If the performance problem
is general, yes. If it is specific to DNS, there's no reason to not use
the connection for other things; and the "send queries to all upstreams"
solution will automatically converge to use the best-performing upstream.

> The downside is that if the lousy ISP wins, hosts are stuck with it.
> This is a serious problem. It may indeed be the case that a better
> choice for non-MPvD hosts is to give them a name server that fans out
> to both ISPs.

On this we are agreed, I think :)

>> How do non-MPvD-aware hosts react to an announcement of an MPvD-specific
>> DNS server? Does it ignore the server entirely, or does it ignore the
>> PvD information and use the server anyway?
>
> It has to be announced in such a way that non-MPvD hosts don't see it.

Right, so if this is the case, how about we specify that routers MAY (or
maybe even SHOULD) support MPvD-specific resolver addresses, and
advertise the fact over HNCP. And that if a router receives such an
announcement from another router it MUST announce the MPvD-specific
resolver addresses over DHCP/RA. This way we ensure that *if* a router
on the network implements MPvD it is going to work for the whole
network; but routers can still opt to not implement the functionality
itself if the implementer doesn't want to pay the implementation cost.


-Toke