Re: Questions re: draft-ietf-mboned-driad-amt-discovery

On 2019-10-24, 11:38, "Warren Kumari" <[email protected]> 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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned