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

Hi Mikael,

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

-Jake

On 2019-01-28, 22:51, "Mikael Abrahamsson" <[email protected]> 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
    
    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.

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

    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?

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


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