Re: [MBONED] WGLC for draft-ietf-mboned-driad-amt-discovery

["Holland, Jake" <[e-mail]>]

Thanks Lenny, much appreciated.  <jh>Responses inline.</jh>

On 2019-04-15, 09:10, "Leonard Giuliano" <lenny=[e-mail]> wrote:

    
    <chair hat off>
    
    Overall, I think this doc is very thorough, clearly written and and
    addresses a much needed area of specification for AMT.  Some comments:
    
    Sect 2.3.2: should the definition of connection completion take into 
    consideration traffic health as well?  That is, the relay is up and happy, 
    but has no multicast connectivity to the source, hence you could have a 
    blackhole.  At the very least, should it be completion of the 3-way 
    handshake?

<jh>
I'm not completely sure what you mean by "3-way handshake" here, but I'm assuming
you mean the one mentioned in RFC 7450, particularly sections 5.1.3 and 5.1.4:
https://tools.ietf.org/html/rfc7450#section-5.1.3
https://tools.ietf.org/html/rfc7450#section-5.1.4

The definition in section 2.3.2 of this draft calls the connection complete
during the 2nd part of this 3-way handshake, which is receipt of the Membership
Query message.  (Since we're talking about a gateway-side decision, I don't
think there's anything the client knows about after the 3rd part of the handshake,
before starting to receive data traffic.)

I agree with you that it would be nice to have information about multicast
connectivity to the source, but I don't think this can be safely discovered when
probing connectivity of multiple connections in parallel (as described by the
Happy Eyeballs part), because if we actually forward the subscription to
one or more (S,G)s to multiple relays, we might start getting traffic from all
of them, and that traffic might be larger than we should receive, or could
result in forwarding multiple copies of packets routinely, if an implementation
doesn't take specific steps to avoid it.

Therefore, the way this doc handles it is to allow multiple connections to
start in parallel up until receiving the Membership Query (which is stage 2 of
the 3-way handshake), and then to pick the most preferred of those connections
to get the Membership Update including a subscription to data traffic, and then
after subscribing, to use the Traffic Health heuristics (section 2.5.4) to decide
whether the gateway needs to restart discovery with a hold-down for the relay that
had bad health on the traffic.

Do you think I need a reference to 2.5.4 in section 2.3.2 to make this more
clear?  Or is there a deeper objection here?
</jh>
    
    Sect 2.3.2: “See Section 2.5.5 for further …”
            -“See Section 2.5.5 of this doctment for further…” to eliminate 
    confusion, as when I first read this, I wasn't sure if it was referring to 
    RFCs 7450 or 8305 (turns out, neither).

<jh>
That sounds fine to me, my local copy is updated to add "of this document" after
the section reference and before "for further...".
</jh>
    
    Sect 2.4.1: How about #6- The application layer includes a suggested relay
    address (as a hint)
            -this is what we’ve done in the VLC with AMT GW build.
    Specifically, VLC has a configurable AMT relay address, which uses a
    well-known FQDN (amt-relay.m2icast.net) which has multiple A records of
    known, healthy relays.  Or is this scenario covered by #3?

<jh>
This scenario is covered by #3.

Do you think we need a definition of "administrative configuration" in section
1.2.2 or something (and maybe "administratively" added before "configured" in
#3)?  I had assumed the concept was reasonably well understood, but  if this
wasn't clear, maybe it's not obvious enough in the text.

(Any WG opinions here on whether #3 is already clear enough on allowing this
usage?)
</jh>
    
    Sect 2.4.2: I found this sect a little tough to follow.  There are 3
    enumerated options, but the text that follows includes other options (like
    admin config).  Also, I found it curious that you have Global Anycast so
    high in the list of prefs (before DRIAD).  Global Anycast seems very
    unlikely to ever be a good deployment option since it’s so vulnerable to
    DoS (recall Mikael and my comments in the mtg in Prague)
<jh>
My presentation in Prague focused largely on why I felt the update to put the
global anycast IP before DRIAD was necessary.  For easy reference, here's a
link to the video (from 3m44s into my presentation, where I begin directly
addressing this point):
https://www.youtube.com/watch?v=jIDYHFpJYV8&t=55m44s

If that was unclear, I guess I'd like to get some more specific questions about
it?

As painful as it is to see myself speak, I re-watched that whole thing, and I
heard Toerless give some comments speaking directly to this question (to which
I responded in another thread [1]), but I think Mikael's comment was not about
this, and I didn't see any mic comments from you about this.  Were there some
other comments you meant to recall?
[1] https://mailarchive.ietf.org/arch/msg/mboned/pgw9SLTUvjSGZ4jGKDjYmyheFOA
</jh>
    
    Anyway, could this section just include a simple list of all the options
    in order of pref?  Something like:
    
    1) DNS-SD
    2) DRIAD
    3) Admin config of GW or App level
    4) Global Anycast address

<jh>
I like this idea, thanks, I think it will make things clearer here.

However, I don't think the ordering you've given is right.  In the absence
of administrative config, I think (pending further discussion of the above
comment) the order would look like this:

   1) DNS-SD
   2) Global Anycast (mainly to support local usage!)
   3) DRIAD

I guess one way to look at this is to just put admin config in the very front:
   0) Administrative config

However, I think in general, administrative config is also capable of doing
things like suppressing one or more of these steps, or changing the ordering
of these steps, or adding other steps that take account of other information
about the network to influence ordering.

In that sense, I'm not sure just sticking "administrative config" on the front
of the list makes as much sense as keeping it outside this list, in order to be
a super-override for the list as a whole.

So my proposed update to incorporate your excellent suggestion for making a
numbered short summary list for easy reference is to make this change:

OLD:
   Accordingly, AMT gateways SHOULD by default prefer relays first by
   DNS-SD if available, then with the anycast addresses defined in
   Section 7 of [RFC7450] (namely: 192.52.193.1 and 2001:3::1), then by
   DRIAD as described in this document (in precedence order, as
   described in Section 4.2.1).

   This default behavior MAY be overridden by administrative
   configuration where other behavior is more appropriate for the
   gateway within its network.

NEW:
   Accordingly, AMT gateways SHOULD by default prefer relays in this
   order:

      1. DNS-SD
      2. Anycast addresses from Section 7 of [RFC7450]
      3. DRIAD

   This default behavior MAY be overridden by administrative
   configuration where other behavior is more appropriate for the
   gateway within its network.

Additionally, I'll remove the numbers on the long-form explanations
above this piece in 2.4.2, since I think multiple different numbering
schemes in the same section would add confusion.

If you think it's better, I could also put this in front of the big
explanations, take out "Accordingly, ", and add in something like "the
reasoning for this preference ordering is described below".  That's not
done in my local copy, but if I get responses with "yes, that's better"
here I'm happy to make the change.  Whatever's most clear would be great.

(Or if that doesn't address your concerns, can you suggest some text that
would, which takes into account the above considerations?  Thanks.)
</jh>
    
    Sect 3.2.1: 1st para, last sentence, “… by finding a A or AAAA records..”
            -“ by finding an A or AAAA record” or “by finding A or AAAA
    records”
<jh>
Fixed locally, thanks.
</jh>
    
    
    Other Relay discovery options- as I mentioned, in the VLC build with AMT,
    we have a configurable option for the relay address with a well-known fqdn
    with multiple A records as the default.  It will then receive all the A
    records as an ordered list and try to use one at a time until it receives
    data.  This method provides relay discovery and resilience, but not
    optimality.  In Prague, got a suggestion from Tom P that you could get
    optimality by pinging each of the relays from the list of A records and
    choosing the one with the lowest latency (or perhaps joining all relays
    and then selecting the one with the healthiest stream and pruning the
    others).  Do you think these options should be mentioned anywhere in this
    doc?
<jh>
I like this idea, and I agree it's a good concept to get into the doc somewhere.
I think it works well as a heuristic that should be mentioned somewhere.

I think recommending ping specifically is a bad idea (it's not so clear that the
ICMP path RTT will be the same as the UDP path RTT), though I guess it's maybe
reasonable in a lot of places.  RTT of the response between sending the Request
packet and receiving the Membership Query packet (plus history of that metric
when it's known) sounds like a better approach in general, so I guess if we're
putting something in about this, I'd like it to capture that usage, or I'd at
least prefer to avoid a mention of ping in particular as compared with other
measurements.

What do you think of a change in section 2.4.2 to integrate this suggestion?
Would this cover what you're looking for?

OLD:
   Among relay addresses that still have an equivalent preference after
   the above orderings, a gateway MUST make a non-deterministic choice
   for relay preference ordering, in order to support load balancing by
   DNS configurations that provide many relay options.  (Note that
   gateways not implementing a Happy Eyeballs algorithm are not required
   to use the Destination Address Selection ordering, but are still
   required to use non-deterministic ordering among equally preferred
   relays.)

NEW:
   Among relay addresses that still have an equivalent preference after
   the above orderings, a gateway MUST make a non-deterministic choice
   for relay preference ordering, in order to support load balancing by
   DNS configurations that provide many relay options.

   The gateway MAY introduce a bias in the non-deterministic choice
   according to network topology or timing information obtained out of
   band or from a historical record.  The collection of this information
   is out of scope for this document, but a gateway in possession of
   such information MAY use it to prefer topologically closer relays.

(This suggestion also cuts out what I think having re-read this bit is
probably a useless side note that happens to be in the same spot, but if
somebody doesn't like the edit, please let me know as a separate point.)
</jh>

<jh>
Thanks very much for your comments, and please anyone feel free to jump
in here with opinions and responses.

Best regards,
Jake
</jh>    
    
    On Fri, 12 Apr 2019, Leonard Giuliano wrote:
    
    | 
    | In Prague, there appeared to be solid support to initiate last call, so we
    | would like to officially begin working group last call for
    | draft-ietf-mboned-driad-amt-discovery.  Please post whether you support/oppose
    | the advancement of this draft as well as any comments you may have to the list
    | by May 3.  Also, please note if you are aware of any IPR involved in this
    | draft (we must hear from the author about IPR).
    | 
    | Most recent version of the draft can be found here:
    | 
    | https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/
    | 
    
    _______________________________________________
    MBONED mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/mboned