IETF Logo Mail Archive

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

Ted Lemon <mellon@fugue.com> Tue, 15 August 2017 13:21 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 8C5B8132198 for <homenet@ietfa.amsl.com>; Tue, 15 Aug 2017 06:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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, URIBL_BLOCKED=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 DwIcQsEXSVXq for <homenet@ietfa.amsl.com>; Tue, 15 Aug 2017 06:21:44 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 23A431320D8 for <homenet@ietf.org>; Tue, 15 Aug 2017 06:21:44 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id v29so4121246qtv.3 for <homenet@ietf.org>; Tue, 15 Aug 2017 06:21:44 -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=tgB49eYNQHkCo7H0YSdvEh0IMplsqJT8X4XdV6NnArc=; b=M0SnQClipQbU8ahjvjbDQNTHDTqV2yueYqnqa/odIEBV0ihyrYgAIakd04HwL05t1s VtyC4Rqmaa0O3xMf5b4+Yk6jRs0WyGHKIJKIaEtYacLYWsx3rd2Bqb8uerq/AiYXTmJO UIz5K9h3ai3rnSqBHUFMSAZh1YU3TggPwYfGHJy47QnfpWTDTFnqtD8ilZy2SlfocKEh D4rdUtI/ywvajIpFU2Yfeejxuwtyde3qvIN0Dcs/vSeP0Uunk5Z3vYp2uecotyq9ynx8 fF8oMjiFgYT8vrx+5SiA8fbrwncDzmjyJYPAPuPB9fQH5WRgAw7P19rJaEi2dxIt19qj MeWA==
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=tgB49eYNQHkCo7H0YSdvEh0IMplsqJT8X4XdV6NnArc=; b=IbTFbHcumy/LHqgTr2pTsFewRvnCzCntN6MvNfudQN3nzSlPcKaNQcogSQzcwOlDvP FYL/wthtRWjSarfBuHvDvFsrL9GgyYg3RzX63sAhr+JxireIpG6do2aS+QRPsQDgd1KY jFFK6fJNFOzSJcwRcf6FAuK5wCRuOGhhZly+sGK9pCD0J9rug64DLIlK2ciZo3feRfwx aSB0U+Iac2qidYDTK8jAQf5qaoIuGiIeXm3/FuOLh1RPPVr3JTy+kt6b6sla31vhKQ6a qndLQeYv5oxK+MkHLhT7r7IQQWSIDGn+D3lScbcSn8f+OmhY8J8Ke+Qe3vTzRb3AnOq4 XVUw==
X-Gm-Message-State: AHYfb5gs94q4UJN0pvgQYvscHgCtnqmUhmuXXCNiT538fe9VGGpv2fSo sRoFiHL5Lucee+JwKYN7cA==
X-Received: by 10.200.39.105 with SMTP id h38mr39482983qth.268.1502803303145; Tue, 15 Aug 2017 06:21:43 -0700 (PDT)
Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id r25sm6378557qki.42.2017.08.15.06.21.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 06:21:41 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <FB44A942-9DE3-4CE6-88C5-402B20756462@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_797AF541-8CF1-4838-8A2B-ED1DD72A91E1"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 15 Aug 2017 09:21:39 -0400
In-Reply-To: <87fuctxdrc.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> <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> <87fuctxdrc.fsf@toke.dk>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/MBWlFnLDFVcUvCAe2rlgAmOHY_Q>
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 13:21:47 -0000

El 15 ag 2017, a les 7:37, Toke Høiland-Jørgensen <toke@toke.dk> va escriure:
> 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...

Simple answer: don't wait five seconds.

> What are you basing this assessment on?

The prevalence of support for MPvD in existing hosts?

> 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.

I think we are wandering off into nonsense territory here.   Have you observed this sort of problem in the field?   If so, can you describe what happened?   If not, why would we optimize for 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.

Can you describe for us what this implementation cost is that you want to avoid?

v2.23.0 | Report a Bug | By Email