Re: [MBONED] Suresh Krishnan's Discuss on draft-ietf-mboned-driad-amt-discovery-10: (with DISCUSS and COMMENT)

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

Hi Suresh,

Thanks for the review.  Responses below:

On 2019-12-17, 19:49, "Suresh Krishnan via Datatracker" <[e-mail]> wrote:
> I think this should be easy to clear up but I think the following text is vague
> and needs be clarified
> 
> "  Among relay addresses that have an equivalent preference as described
>    above, a Happy Eyeballs algorithm for AMT MUST use the Destination
>    Address Selection defined in Section 6 of [RFC6724], as required by
>    [RFC8305]."
> 
> Does this mean that the addresses are sorted as defined in Section 6 of
> [RFC6724] or as defined in Section 4 of [RFC8305] that defines further steps on
> top of RC6724 including ordering by RTTs, address family interleaving etc. I
> think this needs to be stated explicitly.

My intent in this section (including the following paragraphs) was to replace
the further steps from section 4 of RFC 8305 with these steps instead.  I had
thought this was still in scope of the paragraph above the list of preference
orderings that explains we're superseding section 4:

"  Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort
   the addresses with the Destination Address Selection defined in
   Section 6 of [RFC6724], but for the above reasons, that requirement
   is superseded in the AMT discovery use case by the following
   considerations:
"

However, I can see how it comes across as ambiguous after this much
separation.

In particular, I wanted to get different gateways handling roughly
simultaneous joins to spread the load among different relay options,
and not strictly pick the one with the lowest RTT, which in some cases
would be relatively highly shared (I was worried that the stateful
history that prefers lower RTT clause in Section 4 of 8305 could be
read as telling each gateway to always pick the smallest RTT if it's
tracking that).

I also noticed that the "this default behavior MAY be overridden" clause
in the first paragraph suggests, like in one of Mirja's comments about
another section, that the MUSTs here should probably be SHOULDs.

So here's what I propose:

OLD:
   Among relay addresses that have an equivalent preference as described
   above, a Happy Eyeballs algorithm for AMT MUST use the Destination
   Address Selection defined in Section 6 of [RFC6724], as required by
   [RFC8305].

   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 ...
   ... closer relays.>

   Note also that ...

NEW:
   Among relay addresses that have an equivalent preference as described
   above, a Happy Eyeballs algorithm for AMT SHOULD use use the
   Destination Address Selection defined in Section 6 of [RFC6724].

   Among relay addresses that still have an equivalent preference after
   the above orderings, a gateway SHOULD make a non-deterministic choice
   (such as a pseudorandom selection) for relay preference ordering, in
   order to support load balancing by DNS configurations that provide
   many relay options.

   <The gateway MAY introduce a bias ...
   ... closer relays.>

   Within the above constraints, gateways MAY make use of other
   considerations from Section 4 of [RFC8305], such as the address
   family interleaving strategies, to produce a final ordering of
   candidate relay addresses.

   Note also that ...


Would this change address your concerns?

> I had the same question as Barry regarding the "non-deterministic choice"
> wording in the draft. I think it would be good if you can be more specific here.

I responded to Barry about this, and he wrote back.  I'm adopting his suggestion
of "non-deterministic choice (such as a pseudorandom selection)", if that works
for you.

Thanks and regards,
Jake