Re: [MBONED] Questions re: draft-ietf-mboned-driad-amt-discovery

[Warren Kumari <[e-mail]>]

On Sun, Oct 27, 2019 at 3:35 PM Holland, Jake <[e-mail]> wrote:
>
> On 2019-10-24, 11:38, "Warren Kumari" <[e-mail]> 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.
>

I believe that this addresses my concern - another WGLC seems like a
good idea, but I think you could also do a compress, 1 week call only
on the changed text; seeing as this would likely push right into the
draft cutoff, I suspect a regualr WGLC makes more sense.

W



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


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf