Subject: [MBONED] timeouts in draft-ietf-mboned-driad-amt-discovery (was: MBONED WG Call For Adoption: draft-jholland-mboned-driad-amt-discovery)

From: "Holland, Jake" <[email-masked]>
Date: Fri, 25 Jan 2019 22:34:04 +0000

Hi Mikael,

Thanks for your comments, they led me to realize I had left out some
important context. I've submitted a new version of the draft:
https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/

Unfortunately I'm not seeing the diff links from the prior version
in the html--is there a way to get those turned on?  (I assume I
screwed that up when submitting, but I checked and saw it there
for others?)

Anyway, the bulk of the changes are the new section 2.4, plus some
edits to the abstract, and a new next-to-last paragraph in section 2.1.

I've added an explanation that this doc is an update to the relay discovery
process in AMT.  (Which carries with it the defined behavior from RFC
7450: whenever the relay discovery process is restarted, if the gateway
learns a new result, it would send a teardown to the old, and membership
updates to the new relay.)

I've added a section with recommendations structured as non-normative
guidelines and considerations, since experience is still limited with
the protocol operating at scale, and different gateways will sometimes
operate in very different environments.

Among other things, the new guidelines try to address your question
about DNS TTL expiry, but please let me know if you notice any problems.

I expect (and tried to explain in the new text) that making poor choices
with these guidelines would impact quality of service for the tunneled
traffic to some degree, but the basic operation of the protocol should
be unaffected.

Regardless of the choices when following those guidelines, there's some
opportunity for disruption to the traffic, and it'll be relatively
similar-looking whenever a rediscovery event happens.  The guidelines
basically try to advise avoiding them when possible, within reason.

If the gateway is at a network ingest point and you need less
disruption, in practice you'd probably want to run redundant tunnels and
skew the rediscovery timing.  I didn't explicitly address that, do you
think it needs a mention? (And if so, can you suggest any references or
example text from other RFCs?  This seems a pretty normal network design
practice for all kinds of traffic, but I've rarely seen it spelled out.)

(If the gateway is embedded in an app or host, you probably just cry
softly instead.  Or maybe set the app settings to a fixed value if it's
flapping for you.)

Thanks and regards,
Jake

On 2019-01-21, 00:49, "Mikael Abrahamsson" <[email-masked]> wrote:
    What I am missing currently from the draft is how to handle long-lived S,G 
    joins in relationship with these DNS lookups. If the DNS information has 
    3600 seconds TTL, what happens when this DNS information expires. Is the 
    AMT gateway supposed to ask again, what happens if it now receives other 
    information than it received before? Is it supposed to re-evaluate, cease 
    communication with the current set of AMT relays, and re-establish 
    communication with the new ones listed in that preferred order? Or just 
    keep going as long as the current AMT session seems fine?
    
    The words "cache", "lifetime" etc doesn't exist in the draft. I'd like 
    some text on this, even if there is no need to handle it. Then it should 
    explicitly say that lookups are only done at S,G join time or whatever 
    other conditions that might happen within the AMT state machine for error 
    handling/handshakes etc.
    
    -- 
    Mikael Abrahamsson    email: [email-masked]
    
    _______________________________________________
    MBONED mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/mboned

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 29 Jan 2019 07:51:34 +0100 (CET)

> screwed that up when submitting, but I checked and saw it there

http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-jholland-mboned-driad-amt-discovery-03.txt&url2=https://www.ietf.org/id/draft-ietf-mboned-driad-amt-discovery-00.txt

I read that, and your proposed approach to handle this seems fine. 
However, do we really want to make this up to the implementor to decide 
and not have more guidance? Again, I am no AMT expert so I'll defer that 
to people who know more than I do.

I realised another thing.

3.2.1.  Sender-controlled Relays

    When a sender network is also operating AMT relays to distribute
    multicast traffic, as in Figure 6, each address could appear as an
    AMTRELAY RR for the reverse IP of the sender, or one or more domain
    names could appear in AMTRELAY RRs, and the AMT relay addresses can
    be discovered by finding an A or AAAA record from those domain names.

Does this mean there can only ever be a single A *or* AAAA record? What 
happens if there are 2 A records and 3 AAAA records? Which one does it 
use, in what order? Should it implement some kind of "Happy Eyeball" 
functionality to figure out the best way to talk to it?

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 1 Feb 2019 00:52:09 +0000

Hi Mikael,

Thanks for the comments.  Responses inline with <jh></jh>.

-Jake

On 2019-01-28, 22:51, "Mikael Abrahamsson" <[email-masked]> wrote:
...
    http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-jholland-mboned-driad-amt-discovery-03.txt&url2=https://www.ietf.org/id/draft-ietf-mboned-driad-amt-discovery-00.txt

<jh>
I'm trying to avoid formalizing bad advice that might accidentally get
implementations to do things that will disrupt the steady state
forwarding of traffic that's working well.  The main idea is "don't
rediscover when things traffic is flowing and everything's fine", plus
"here's all the indications I can think of that things aren't fine".

So although your point is well-taken, I think it's going to take some
more deployment experience before there's really solid advice to give
about fine tuning the rediscovery timing, especially considering the
different intended deployment environments.

On reflection, I'm even thinking the DNS expiry might be a bad idea to
include in the list of events that should cause a restart of
discovery--if you're connected to a relay that's working, it's probably
a good idea to stay with the relay you found. I'm not sure that point is
strong enough in 2.4.2 (Tunnel Stability), so maybe I'll add a SHOULD to
that effect and take out DNS expiry from the list of recommended events
that can trigger a restart of discovery.

That said, if you've learned a DNS record that expired 2 weeks ago, it
might not be a bad idea to re-discover from time to time, especially if
traffic is low, or there's no traffic actually joined.  So I'll maybe
add a note to that effect in the Flow Health or Tunnel Stability section
instead?

I'll think about it a bit and take my best guess. Suggestions are
welcome. :)
</jh>

    

<jh>
Good catch, thanks.  The intent was that all A and AAAA records resolved
from the domain name given by a type 3 AMTRELAY RR would be treated as
having the precedence from that RR.

I'll try to fix the wording in section 4.2.4 to clarify that for type 3
AMTRELAY RRs, when there are multiple A or AAAA for the domain name,
they should be treated for relay discovery the same as if there had been
multiple AMTRELAY records of type 1 for A or type 2 for AAAA, with the
same precedence and D-bit as the original type 3 RR (so there should be
a non-deterministic choice between the different options).

There was a mention of something similar to Happy Eyeballs, but I'm now
noticing it was buried in the last 2 paragraphs of 3.1.2:

   The discovery and connection process for multiple relays MAY operate
   in parallel, but when forwarding multicast group membership reports
   with new joins from an AMT gateway, membership reports SHOULD be
   forwarded to the most-preferred relays first, falling back to less
   preferred relays only after failing to receive traffic for an
   appropriate timeout, and only after reporting a leave to any more-
   preferred connected relays that have failed to subscribe to the
   traffic.

   It is RECOMMENDED that the default timeout for receiving traffic be
   no less than 3 seconds, but the value MAY be overridden by
   administrative configuration, where known groups or channels need a
   different timeout for successful application performance.

Maybe I should make that a more formal Happy Eyeballs reference?

I could maybe add a "Happy Eyeballs" section, make a reference to RFC
8305, and define a "connection" in this context as receipt of a
Membership Query from the relay without the L flag set.  The idea would
be to proceed in parallel for multiple candidates through Relay
Discovery + Relay Advertisement (if D-bit), then Request + Membership
Query response, and pick the best candidate that succeeds and did
not set the L flag.

I think I like that idea, at first glance.  I'll give it a little
more thought and aim to push an update hopefully sometime next week.

Please let me know if any of these ideas seem like a wrong approach, or
if you've got any other comments or questions, but I hope the next
update will address the issues you've raised so far.

Thanks again.

-Jake
</jh>