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

On Tue, 23 Apr 2019, Holland, Jake wrote:

| <jh2>replies inline, and thanks Lenny!</jh2>
| 
| On 2019-04-23, 12:32, "Leonard Giuliano" <[email protected]> wrote:
|     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.
| <jh2>
| Does this work for you?
| 
| OLD:
|    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.
| 
| NEW:
|    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.
| </jh2>

Looks good.


|         
|     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.
|     
| <jh2>
| Ah, I see.  Thanks for pointing me there, now I remember.
| 
| Yes, I agree global anycast is a blackhole waiting to happen, and won't
| see wide deployment until at least after there's a way to do good brokering
| somehow.
| 
| What I'm trying to suggest here is that if you're an ISP providing multicast
| connectivity, and you're deploying a relay near the end user edge, you can put
| the global anycast address on that AMT relay and expect it to be discovered by
| gateways inside your customers' networks.*  (I think you've got that picture,
| just wanted to check to make sure.)
| 
| In the case when the ISP isn't supporting multicast and hasn't deployed a relay,
| this means the gateway will try to discover the global anycast, hopefully in parallel
| with the DRIAD discovery, with a slight head start (under the happy eyeballs logic).
| 
| But yes, if it gets a response from the global anycast about the discovery, it'll use
| that by preference under the latest proposal, maybe discover it's a black hole, and
| then fail over to the DRIAD version according to 2.5.5.
| 
| Do I understand correctly that this 2nd case is what you're most concerned about
| with the preference ordering that puts the global anycast ahead of DRIAD?

Yes, I would put DRIAD ahead of global anycast, but also that local relays 
should be preferred ahead of DRIAD.  And yes, I recognize the potential 
contradiction/tension here.  See below for suggested resolution...

| 
| I agree that this can also be solved by administrative configuration, so that ISPs
| operating a relay local to their customers can tell their customers to configure a
| particular address or hostname on their gateways.
| 
| However, by specifying that gateways should search for one particular thing (such as
| the existing anycast address), we can hopefully make it possible for the ISPs to deploy
| a relay without having to get all their customers to configure their gateways, even
| where DNS-SD doesn't work (which I think is up to the router in the customer network,
| which the ISP might not control).
| 
| I see this as especially important for ISPs with customers that may have a lot of
| mobile devices coming and going, with wifi hotspots or something, because you can't
| get those devices to configure the gateway, so if the ISP can't capture the joins
| when the customer network isn't operating its own local AMT relay, the ISP can't
| really get those devices to make use of its multicast-enabled network instead of
| discovering their own unicast tunnels.
| </jh2>
| 
|     | </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.
| ...
|     
|     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?
| 
| <jh2>
| Well, this is about the behavior of the gateways performing discovery, and I
| wanted something that the ISP can deploy which will definitely work, when
| DNS-SD doesn't in some places.
| 
| My problem is that the gateway can't easily distinguish between a local relay
| it found with the global anycast address and a remote relay it found with the
| global anycast address.

Yeah, that's why I suggested the "may or may not use the global anycast 
address" verbage to provide enough wiggle room one way of the other.  I 
recognize that these are vague and imprecise terms (eg, "local" is 
relative), but I'm thinking this early in evolution might be premature to 
optimize on a precise solution; it's more important to document the range 
of options for understanding and provide enough flexibility for future 
(potentially unimagined) innovations.

| 
| Maybe a good solution is to explicitly allow a DRIAD relay with a shorter RTT
| to be preferred to the global anycast...  Would that cover your concerns?

Nah, probably too complex to rely upon.

| 
| I think this is allowed already with happy eyeballs--the gateway would have to
| give the global anycast a particular minimum head start, but I think if the
| connection finishes with DRIAD first, that could be used.  But maybe another
| similar alternative is that if there's a recent history of failing with the
| global anycast, it could be skipped--would that work too?
| </jh2>
|     
|     And having a simple numbered list with explanations for each, and perhaps 
|     rationalization for the order, sounds like agood approach.
|     
|     
|     | NEW:
| ...
|     |    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 ..."?
| <jh2>
| I like adding "probing mechanism", thanks.  Do you object to keeping "timing
| information"?  I'm thinking maybe a minor refinement here to make a bigger list
| work better:
| 
| NEW:
| "
| ... according to information obtained out of band or from a historical
| record about network topology, timing information, or the response to a
| probing mechanism, that indicates some expected benefits from selecting
| some relays in preference to others.  Details about the structure and
| 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.
| "

Looks good!

| 
| (suggestions welcome on tightening that up, but I prefer to keep timing
| information if possible.)
| </jh2>
| 
| 
| 

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