Re: WGLC for draft-ietf-mboned-driad-amt-discovery

Jake- sorry for the delayed reply, took some time to fully digest.
Comments inline, and let me know if you already covered this in the 
lastest version:

On Mon, 15 Apr 2019, Holland, Jake wrote:

| Thanks Lenny, much appreciated.  <jh>Responses inline.</jh>
| 
| On 2019-04-15, 09:10, "Leonard Giuliano" <[email protected]> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7450-23section-2D5.1.3&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=GnlMUunygK9RB-Dv7QFmxyc6Mk8ZVbhA6DdDeV4slPA&e=
| https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7450-23section-2D5.1.4&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=9Z1ODsciEKqfCyQy8UvMrp9JOlQ8M2MzuTOAut8dee4&e=
| 
| 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?

Yeah, I think that would be helpful, as I didn't quite get that 
connection.  Again, I'm concerned with the case where the AMT tunnel comes 
up but the relay lacks multicast connectivity to the source, which I 
suspect will not be an uncommon case.  As you've worded above- probe the 
relays til you get a good session, then join, then pick another relay if 
you get no data, sounds reasonable to me.  I think making that clear in 
2.3.2 would be helpful.

| </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?)

OK, re-reading, I'm convinced #3 is good enough to get this idea across, 
though if others have an opinion, please speak up.

| </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://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DjIDYHFpJYV8-26t-3D55m44s&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=UUvXd2wmB1kONtQbcaewEPwiIY3HFmclRqqq4S_ruBo&e=
| 
| 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://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_mboned_pgw9SLTUvjSGZ4jGKDjYmyheFOA&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=rUqinpiSDianQ6D3sbqDY4e0VquYNevgB61tr3kPxeY&e=

In the same video (mboned mtg recording), I talked about this at 1:23:20 
till ~ 1:26:00 and then Mikael confirmed my suspicions that it was a bad 
idea at 1:31:20.  Bottom line is Global Anycast is a backhole waiting to 
happen, so I don't think it'll be a viable deployment option.  Now, local 
relays using anycast addresses from a provider's space, such that each AMT 
provider will have it's own anycast set (analogous to anycast RPs), does 
seem like it'll be a good deployment option.

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

OK, what you suggest for the admin config sounds reasonable and does 
provide ample wiggle room for flexibility.  I am still a bit nervous about 
having Global Anycast, a mechanism so fraught with peril, ahead of DRIAD, 
though I do understand your pref for local relays.  What if you mentioned 
something like "#2 Locally deployed relays in the receiver's ISP, which 
may (or may not) utilize the Anycast addresses from Section 7 of 
[RFC7450]"?  Or must it use the global anycast addresses?

And having a simple numbered list with explanations for each, and perhaps 
rationalization for the order, sounds like agood approach.


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

How about "... according to network topology or response to some sort of 
probing mechanism obtained ..."?

| 
| (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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Ddriad-2Damt-2Ddiscovery_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=bdXOvMCVQ0eopeNSHcSHJLpx0E8A_abVYFeOYvbtwVw&e=
|     | 
|     
|     _______________________________________________
|     MBONED mailing list
|     [email protected]
|     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=cfmFRgGtQ5R5k-SgsRnt8-P5lkvvJ_5apkUetxJjkm0&e=
|     
| 
| 

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