Re: [MBONED] Questions re: draft-ietf-mboned-driad-amt-discovery
"Holland, Jake" <jholland@akamai.com> Sun, 27 October 2019 19:35 UTC
Return-Path: <jholland@akamai.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EC5120024 for <mboned@ietfa.amsl.com>; Sun, 27 Oct 2019 12:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=akamai.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 gHUe6BH41pSC for <mboned@ietfa.amsl.com>; Sun, 27 Oct 2019 12:35:42 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 6D504120046 for <mboned@ietf.org>; Sun, 27 Oct 2019 12:35:42 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9RJW070003692; Sun, 27 Oct 2019 19:35:40 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=y/7hGOqu5q2rDdb38trHqc/mJVzcD14WiCE9yoLEzGw=; b=evp1NnXQGjNlr70e2fcEfoNsMxlvoSZ49MosfeL4dFNkCUVPQqzt+KnWWQh5uj4hk8EJ LO/Sp/qfqAj+PiezooxLswdhqLpoO7ZbwXNQjBXPPqxF4NNsxF2mEvlwJsAI+SROEUER gL4/EEqI+pCPf1IGzldI1mdWFglG4+FQGS/jPxdBLM+pk510H6kA5lIY0MzgMTG44pxH BIMtxeXiNgFnH1ImdlduvbR17wiNYJaeh17mEfXbw/6R0dcJbygTF3BoCkCxKlK6GuIs xWHFpmBiKoanpRty4okl39PuRklrmXzUI2VMYmnCYVD6G27ujKL4QAZhxLwlqsEeZ8vA eA==
Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2vve6hpe4u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 27 Oct 2019 19:35:40 +0000
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9RJWPjP020376; Sun, 27 Oct 2019 15:35:39 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint8.akamai.com with ESMTP id 2vvhfvphkn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 27 Oct 2019 15:35:38 -0400
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.165.122) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 27 Oct 2019 14:35:38 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.165.122]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.165.122]) with mapi id 15.00.1473.005; Sun, 27 Oct 2019 14:35:38 -0500
From: "Holland, Jake" <jholland@akamai.com>
To: Warren Kumari <warren@kumari.net>
CC: MBONED WG <mboned@ietf.org>
Thread-Topic: [MBONED] Questions re: draft-ietf-mboned-driad-amt-discovery
Thread-Index: AQHVgyMTR8NvJMYgxky2YEV/YIJZo6de4uUAgACC8gCACxwVAIAEUa8A
Date: Sun, 27 Oct 2019 19:35:37 +0000
Message-ID: <D118AC40-331E-4C42-83E6-719DB8350B15@akamai.com>
References: <CAHw9_iJ5MYoCUY-hRysEfpnYfkmogbfAfhGaqvEDpCn4h9f=OQ@mail.gmail.com> <65D61935-47C9-42D1-AE9C-D4FB5B2A0B31@akamai.com> <CAHw9_iKD9U7cEzTwmTok-8Dp96i6wpW4R+4P+6oMQkGB_j8+_g@mail.gmail.com> <CAHw9_iLWS2O3JqwTJGFpcxzq-UVfN-LURU9Fg5r2j615+XBmvQ@mail.gmail.com>
In-Reply-To: <CAHw9_iLWS2O3JqwTJGFpcxzq-UVfN-LURU9Fg5r2j615+XBmvQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.80.155]
Content-Type: text/plain; charset="utf-8"
Content-ID: <691C0B5F28D39D4FA03D0EE8A382F9C0@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-27_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910270203
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-27_08:2019-10-25,2019-10-27 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 adultscore=0 malwarescore=0 spamscore=0 bulkscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 phishscore=0 clxscore=1011 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910270203
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/L6jO4lHGPb3_y34Lxy5wnoQIBAw>
Subject: Re: [MBONED] Questions re: draft-ietf-mboned-driad-amt-discovery
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Oct 2019 19:35:44 -0000
On 2019-10-24, 11:38, "Warren Kumari" <warren@kumari.net> wrote: >> Thank you. Please SHOUT LOUDLY once you've had a chance to do so (and >> / or poke me), so I don't miss it. > > Checking in to see if you've had a chance to make progress.. > W Hi Warren, Thanks for checking in. I got a little sidetracked on a different thing, sorry for the delay, but I came up with an attempt. I moved the "Happy Eyeballs" section after the "Optimal Relay" section, (so it becomes 2.4 instead of 2.3, and "Optimal Relay" becomes 2.3 but is otherwise unchanged), and added an "Application Guidelines" sub-section, to explain how it maps to RFC 8085's algorithm outline, plus refactored a bit of the existing text. This adds a requirement, because I noticed while writing it up that it's probably necessary to mention a rate limit, at least. Anyway, hopefully it's less vague, and thanks Warren and Tim for pointing that out. Would this text address both of your concerns? I guess this is a big enough proposed change that we should probably do another wglc (although I'd be happy to take an excuse not to wait 2 weeks if one is readily available). But either way, please take a look and let me know if you see any problems in this text, or have any suggestions to improve it. Absent any feedback I'll post it to -09 more or less like this before the Singapore submission deadline, and go from there. ----- OLD: (see: https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-08#section-2.3 or it's pasted at the bottom for reference) NEW: 2.4. Happy Eyeballs 2.4.1. Overview Often, multiple choices of relay will exist for a gateway using DRIAD for relay discovery. Happy Eyeballs [RFC8305] provides a widely deployed and generalizable strategy for probing multiple possible connections in parallel, therefore it is RECOMMENDED that DRIAD- capable gateways implement a Happy Eyeballs [RFC8305] algorithm to support fast discovery of the most preferred available relay, by probing multiple relays concurrently. The parallel discovery logic of a Happy Eyeballs algorithm serves to reduce join latency for the initial join of an SSM channel. This section and Section 2.3.2 taken together provide guidance on use of a Happy Eyeballs algorithm for the case of establishing AMT connections. Note that according to the definition in Section 2.4.3, establishing the connection occurs before sending a membership report. As described in Section 5 of [RFC8085], only one of the successful connections will be used, and the others are all canceled or ignored. In the context of an AMT connection, this means the gateway will send membership reports receive data for only the chosen connection after the concurrent racing of the Happy Eyeballs algorithm is resolved. 2.4.2. Algorithm Guidelines During the "Initiation of asynchronous DNS queries" phase described in Section 3 of [RFC8305]), a gateway attempts to resolve the domain names listed in Section 2.3. This consists of resolving the SRV queries for DNS-SD domains for the AMT service, as well as the AMTRELAY query for the reverse IP domain defined in this document. Each of the SRV and AMTRELAY responses might contain one or more IP addresses, (as with type 1 or type 2 AMTRELAY responses, or when the SRV Additional Data section of the SRV response contains the address records for the target, as urged by [RFC2782]), or they might contain domain names (as with type 3 responses from Section 4.2.3 or an SRV response without an additional data section). When present, IP addresses in the initial response provide resolved destination address candidates for the "Sorting of resolved destination addresses" phase described in Section 4 of [RFC8085]), whereas domain names in the initial response result in another set of queries for AAAA and A records, whose responses provide the candidate resolved destination addresses. Since the SRV or AMTRELAY responses don't have a bound on the count of queries this process might generate aside from the bounds imposed by the DNS resolver, it's important for the gateway to provide a rate limit on the DNS queries. The DNS query functionality is expected to follow ordinary standards and best practices for DNS clients. A gateway MAY use an existing DNS client implementation that does so, and MAY rely on that client's rate limiting logic to avoid issuing excessive queries. Otherwise, a gateway MUST provide a rate limit for the DNS queries, and its default settings MUST NOT permit more than 10 queries for any 100-millisecond period (though this MAY be overridable by administrative configuration). As the resolved IP addresses arrive, the Happy Eyeballs algorithm sorts them according to the requirements given in Section 2.3.2, and attempts connections with the corresponding relays under the algorithm restrictions and guidelines given in [RFC8085] for the "Establishment of one connection, which cancels all other attempts" phase. 2.4.3. Connection Definition Section 5 of [RFC8305] non-normatively describes success at a connection attempt as "generally when the TCP handshake completes". There is no normative definition of a connection in the AMT specification [RFC7450], and there is no TCP connection involved in an AMT tunnel. However, the concept of an AMT connection in the context of a Happy Eyeballs algorithm is a useful one, and so this section provides the following normative definition: o An AMT connection is completed successfully when the gateway receives from a newly discovered relay a valid Membership Query message (Section 5.1.4 of [RFC7450]) that does not have the L flag set. See Section 2.5.5 of this document for further information about the relevance of the L flag to the establishment of a Happy Eyeballs connection. See Section 2.5.4 for an overview of how to respond if the connection does not provide multicast connectivity to the source. To "cancel" this kind of AMT connection for the Happy Eyeballs algorithm, a gateway that has not sent a membership report with a subscription would simply stop responding to AMT traffic on that connection. A gateway only sends a membership report to a connection it has chosen as the most preferred available connection. ----- Best, Jake PS: For reference, the -08 text: 2.3. Happy Eyeballs 2.3.1. Overview Often, multiple choices of relay will exist for a gateway using DRIAD for relay discovery. It is RECOMMENDED that DRIAD-capable gateways implement a Happy Eyeballs [RFC8305] algorithm to support connecting to multiple relays in parallel. The parallel discovery logic of a Happy Eyeballs algorithm serves to reduce join latency for the initial join of an SSM channel. This section and Section 2.4.2 taken together provide guidance on use of a Happy Eyeballs algorithm for the case of establishing AMT connections. 2.3.2. Connection Definition Section 5 of [RFC8305] non-normatively describes success at a connection attempt as "generally when the TCP handshake completes". There is no normative definition of a connection in the AMT specification [RFC7450], and there is no TCP connection involved in an AMT tunnel. However, the concept of an AMT connection in the context of a Happy Eyeballs algorithm is a useful one, and so this section provides the following normative definition: o An AMT connection is completed successfully when the gateway receives from a newly discovered relay a valid Membership Query message (Section 5.1.4 of [RFC7450]) that does not have the L flag set. See Section 2.5.5 of this document for further information about the relevance of the L flag to the establishment of a Happy Eyeballs connection. See Section 2.5.4 for an overview of how to respond if the connection does not provide multicast connectivity to the source.
- [MBONED] Questions re: draft-ietf-mboned-driad-am… Warren Kumari
- Re: [MBONED] Questions re: draft-ietf-mboned-dria… Holland, Jake
- Re: [MBONED] Questions re: draft-ietf-mboned-dria… Warren Kumari
- Re: [MBONED] Questions re: draft-ietf-mboned-dria… Warren Kumari
- Re: [MBONED] Questions re: draft-ietf-mboned-dria… Holland, Jake
- Re: [MBONED] Questions re: draft-ietf-mboned-dria… Warren Kumari
- Re: [MBONED] Questions re: draft-ietf-mboned-dria… Holland, Jake
- [MBONED] WGLC: Re: Questions re: draft-ietf-mbone… Greg Shepherd
- Re: [MBONED] WGLC: Re: Questions re: draft-ietf-m… Kyle Rose
- Re: [MBONED] WGLC: Re: Questions re: draft-ietf-m… Holland, Jake
- Re: [MBONED] WGLC: Re: Questions re: draft-ietf-m… Kyle Rose
- Re: [MBONED] WGLC: Re: Questions re: draft-ietf-m… Leonard Giuliano