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

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

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.

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?

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

(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