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

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Oct 2019 08:37:01 +0200

Hi there,

Apologies, I just realized that I'd never actually sent this mail
(which explains why I hadn't gotten a reply!) - sorry.

Thank for writing this - I found it to be very well written, clear and
understandable, however there is one (small) issue which I think needs
addressing before I kick off IETF LC.

While doing my AD review of draft-ietf-mboned-driad-amt-discovery I
looked at the Shepherds Writeup (thanks Tim) and saw:
"I would suggest that the text in 2.3.1 on applying a Happy Eyeballs
algorithm where there are multiple choices for the relay be expanded;
it is very vague at present.  I presume that this may result in
multiple unicast AMT streams coming in to a given gateway, and all but
one of these would be pruned back, but some specifics on that, and how
the preferred stream is retained, would be useful. This also needs to
be set against the proposed active/active failover mode described in
2.4.3."

I think it would be really useful if this could be done before I start
IETF LC; I also found this vague, and think that it will get lots of
comments / questions querying LC.

I also have a minor nit:
Section 2.2.  Signaling and Discovery:

   2.  The join propagates with RPF through the multicast-enabled
       network with PIM [RFC7761] or another multicast routing
       mechanism, until the AMT gateway receives a signal to join the
       (S,G).

There are multiple multicast-enabled networks being discussed here,
and "the multicast-enabled network" is vague as to which one is being
discussed -- I'm not quite sure how to fix it though -- I tried "the
local multicast-enabled", this seems better, but still not great.

W

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

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 17 Oct 2019 14:10:10 +0000

Thanks Warren,

Responses inline with [JH].

On 2019-10-14, 23:37, "Warren Kumari" <[email-masked]> wrote:
...

[JH] OK, thanks for the feedback (and to Tim).  I'll try to come up with
some language to address this.  It'll take a little thought on how to
make it less vague without importing the happy eyeballs specs, but
I'm sure there's a happy medium somewhere.

I also have a minor nit:
...

[JH] Thanks for pointing that out.  What do you think of just adding
"receiver's"?  Like this:

OLD:

NEW:
   2.  The join propagates with RPF through the receiver's multicast-
       enabled network with PIM [RFC7761] or another multicast routing
       mechanism, until the AMT gateway receives a signal to join the
       (S,G).

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 Oct 2019 16:58:50 +0200

> I'm sure there's a happy medium somewhere.

Thank you. Please SHOUT LOUDLY once you've had a chance to do so (and
/ or poke me), so I don't miss it.

> [JH] Thanks for pointing that out.  What do you think of just adding

Wow, that's simple and easy - thanks.
W

---

From: Warren Kumari <[email-masked]>
Date: Thu, 24 Oct 2019 14:38:12 -0400

> / or poke me), so I don't miss it.

Checking in to see if you've had a chance to make progress..
W

---

From: "Holland, Jake" <[email-masked]>
Date: Sun, 27 Oct 2019 19:35:37 +0000

> Checking in to see if you've had a chance to make progress..

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.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 27 Oct 2019 17:48:37 -0400

> let me know if you see any problems in this text, or have any suggestions

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

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 28 Oct 2019 02:56:38 +0000

> draft cutoff, I suspect a regualr WGLC makes more sense.

Thanks Warren.

I went ahead and posted it:
https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-09
https://tools.ietf.org/rfcdiff?url2=draft-ietf-mboned-driad-amt-discovery-09.txt

I'm good with whatever the chairs think is best to give people a chance
to look it over.

Best regards,
Jake

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 28 Oct 2019 09:03:19 -0700

The open comments were addressed.

1 Week WGLC. Please respond again, with/without support by Nov 4.

Chairs
(Shep)

On Sun, Oct 27, 2019 at 7:56 PM Holland, Jake <[email-masked]> wrote:

> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>

---

From: Kyle Rose <[email-masked]>
Date: Mon, 28 Oct 2019 12:52:40 -0400

> 1 Week WGLC. Please respond again, with/without support by Nov 4.

Re: "connection", RFC 7450 uses "connection" in a relevant way in exactly
one place (4.1.4 Deployment) but (as noted in this draft) fails to define
it. It does repeatedly refer to a three-way handshake, however, so perhaps
text should be added to this draft to make it clear that "connection" is
(AFAICT) being defined as completion of the first two steps of the
three-way handshake from 7450.

Re: the DNS rate limiting, what motivated the numbers in the normative:

q( 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)

Happy to know if I just missed a discussion thread someplace.

OW, looks good. Ship it.

Kyle

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 28 Oct 2019 20:48:53 +0000

Hi Kyle,

From: Kyle Rose <[email-masked]>
> (AFAICT) being defined as completion of the first two steps of the three-way
> handshake from 7450. 

Something like that originally occurred to me, but I think DRIAD's
formulation disagrees with the simple form of that, because of a disconnect
in the handling of the L flag.

I'll tentatively call this suggestion "rejected with due consideration"
unless you want to discuss more, but here's the reasoning so that
anyone who disagrees can poke holes or propose some language that
handles it:

From https://tools.ietf.org/html/rfc7450#section-5.1.4
   The successful delivery of this message to a gateway marks the start
   of the second stage in the three-way handshake used to create or
   update tunnel state within a relay.

This makes no mention of the L-flag; receipt of the Membership Query is
the second stage of the 3-way handshake regardless of the L-flag value.

From https://tools.ietf.org/html/rfc7450#section-5.1.4.4
   (5.1.4.4.  Limit (L) Flag)
     ...   A gateway checks
   this flag before attempting to create new group subscription state on
   the relay to determine whether it should restart relay discovery.

DRIAD differs on this point for purposes of Happy Eyeballs by calling it
"not a connection" when a Membership Query arrives with the L flag, rather
than calling it a connection that should restart the discovery process:

From https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-09#section-2.4.3:
   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.

So I thought I'd just state the normative connection definition the way
that produces a better behavior, and ignore the independent existence on
the side of the three-way handshake concept.

I also didn't think it left things unclear, because the three-way
handshake isn't explicitly defined in its own terms either or used very
heavily in RFC 7450, it's just mentioned as the 3 involved message types
being stages of it, and then referred to in the security considerations
for pointing out that it protects against source-spoofing.

I thought trying to lay all that out would add more complication than
any confusion it would resolve by pointing out that the connection is
happening during the 3-way handshake, and that it's better to just leave
the definition of a connection for Happy Eyeballs purposes as its own
separate thing.

But do let me know if you have a suggestion for language that you think
would help, I'm not claiming the definition is perfect, just that it's
not obvious to me that it would improve by folding in a three-way
handshake mention.

> its default settings MUST NOT permit more than 10 queries for any

The first and biggest motivation is that I thought _some_ numbers should be
present.  It matters less what they are than that there is something.

The specific numbers chosen were from roughly eyeballing it as equivalent to
10 TCP connections within a second with a 10 initial cwnd, which isn't out of
line with what browsers often might do today while opening a web page, and
so at a roughly "not harmful" level suitable for a default.

In practice I'm expecting that real life deployments will mostly just use a
getaddrinfo call that's backstopped on their systems by dnsmasq's
--dns-forward-max.  But I just get kinda twitchy whenever I see places where
some remote process can cause some local process to send an unbounded number
of packets, so I thought I'd flag it so the engineer tasked with writing it
has an excuse to insist on a limit when his boss wants to do something clever.

I also thought it important because in Happy Eyeballs the DNS resolution phase
(section 3 of 8305) says "Both queries SHOULD be made as soon after one another
as possible", but this assumes we're talking about exactly 2 queries for a
single known hostname, not a chain of 2 queries one of which can produce
several hostnames, so I thought some mention of a limit was warranted.

When you ask about motivations I have to admit I put this in more to ease
my troubled soul than because I think it'll really prevent a problem on
someone's network in practice, based on any kind of sound measurements.  But
of course suggestions are welcome on improved language here.

> Happy to know if I just missed a discussion thread someplace.
Not that I know of...

> OW, looks good. Ship it.
Thanks.

Best regards,
Jake

---

From: Kyle Rose <[email-masked]>
Date: Tue, 29 Oct 2019 09:03:13 -0400

On Mon, Oct 28, 2019 at 4:48 PM Holland, Jake <[email-masked]> wrote:

> unless you want to discuss more

I am convinced by your explanation. Thanks.

> ...snip...

Sounds reasonable. I don't really have any suggestions; it just feels weird
to specify a hard limit without any reference to downstream demand: should
a gateway in a residential CPE have the same rate limit as a gateway on a
corporate border router? Of course not. But I suppose that's exactly the
point of a default limit, in that it forces the vendor or operator to make
a different choice intentionally.

Kyle

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 29 Oct 2019 11:03:24 -0700

<chair hat off>

No complaints about the new text and changes.  I still support

On Mon, 28 Oct 2019, Greg Shepherd wrote:

| The open comments were addressed. 
| 1 Week WGLC. Please respond again, with/without support by Nov 4.
| 
| Chairs
| (Shep)
| 
| On Sun, Oct 27, 2019 at 7:56 PM Holland, Jake <[email-masked]> wrote:
|       On 2019-10-27, 14:49, "Warren Kumari" <[email-masked]> wrote:
|       > 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.
| 
|       Thanks Warren.
| 
|       I went ahead and posted it:
|       https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-09
|       https://tools.ietf..org/rfcdiff?url2=draft-ietf-mboned-driad-amt-discovery-09.txt
| 
|       I'm good with whatever the chairs think is best to give people a chance
|       to look it over.
| 
|       Best regards,
|       Jake
| 
| 
|       _______________________________________________
|       MBONED mailing list
|       [email-masked]
|       https://www.ietf.org/mailman/listinfo/mboned
| 
| 
|