Subject: [MBONED] Mirja Kühlewind's No Objection on draft-ietf-mboned-driad-amt-discovery-09: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Thu, 12 Dec 2019 10:18:32 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mboned-driad-amt-discovery-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing the TSV-ART review (and thanks Bernard for the review!)!
Based and in addition to that review, I have a few more small comments:

1) Minor wording comment on this point in 2.5.2:
"   8.  When congestion or substantial loss is detected in the stream of
       AMT packets from a relay."
I think is should be "substantial congestion or substantial loss" or just
"substantial congestion". But actually I would even maybe say "substantial and
persistent congestion" or maybe even use "(network) overload" instead of
"congestion" because I think that what you are actually looking for.

2) And on this sentence in section 2.7 again:
"with a RECOMMENDED initial_timeout
   of 1 second and a RECOMMENDED maximum_timeout of 120 seconds."
Why do you even specify a max value at all? I think it's more common to define
an initial value and a max number of retries.

3) I have an additional question on this part in 2.4.2:
"Otherwise, a gateway MUST provide a rate limit
   for the DNS queries, and its default settings MUST NOT permit more
   than 10 queries for any 100-millisecond period (though this MAY be
   overridable by administrative configuration)."
Where do these numbers come from?

4) Editorial: I would recommend to have the examples (section 3) before section
2. And I saw that there is one normative requirement in the examples section
(3.2.2.); that's easy to overlook. I would recommend to move it somewhere as or
make it not normative.

5) Sec 6.3:
"Application implementors and network operators that use DRIAD-capable
   AMT gateways..."
Thanks for noting this down. However, I'm wondering if DRIAD-capable AMT
gateways are in this respective any different that non-DRIAD-capable AMT
gateways? However, I think would be good or actually is needed to point to and
discuss section 4.1.4.2.  on Congestion Considerations in RFC7450! Further
regarding the security consideration in general I would also recommend to point
to the security considerations section of RFC7450 and double-check if there is
no change based on the potential different location of the reply (than assumed
in RFC7450).

6) (Important) nit:
In section 2.4.2:
"When present, IP addresses in the initial response provide resolved
   destination address candidates for the "Sorting of resolved
   destination addresses" phase described in Section 4 of [RFC8085]),"
and
"and attempts connections with the corresponding relays
   under the algorithm restrictions and guidelines given in [RFC8085]
   for the "Establishment of one connection, which cancels all other
   attempts" phase."
These should be references to RFC8305 (and not RFC8085).

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 12 Dec 2019 23:13:19 +0000

Hi Mirja,

Thanks for the review.

Sorry for the delay on -10, I pushed it earlier today (having heard no
objections to the edits proposed), but it doesn't yet incorporate edits
addressing your comments, so I'll push another version to address these.

Responses below.

> "congestion" because I think that what you are actually looking for.

OK, sure.  How about this:

  8.  When substantial loss, persistent congestion, or network overload is
     detected in the stream of AMT packets from a relay.

I pushed back a little on "substantial and persistent congestion" when
Bernard suggested it, because I think even minor and persistent would in
some cases be worth changing relays over.

But I'd be comfortable with the above wording, if that addresses your
concerns.

> an initial value and a max number of retries.

I was copying from the advice in RFC 7450 Section 5.2.3.4.3:
https://tools.ietf.org/html/rfc7450#section-5.2.3.4.3

My intent here is to have an essentially similar behavior to that, in spite
of the different way that problems would be discovered here.

I think reaching the max timeout is a good indication something is broken,
but I think abandoning the attempt to forward the data (by stopping after
a max number of retries) isn't appropriate because this is likely happening
in an intermediate node that is not the receiving endpoint.

Hopefully the downstream receiving endpoint also will time out and leave the
group when nothing ever happens, and this would mean the gateway would stop
having a reason to try to connect to a relay.  However, if the receiver
remains joined to the group, I think the network should continue permitting
the forwarding of traffic, should it resume later.  (Or at least, the AMT
gateway should not be the entity that determines that the traffic is dead
enough to abandon.)

> Where do these numbers come from?

I discussed that a little bit on the mboned list when Kyle raised a
similar question:
https://mailarchive.ietf.org/arch/msg/mboned/W82s7f3JqjQmLKsfpSAPg2HUuos

Quoting from there:
The specific numbers chosen were from roughly eyeballing it as equivalent to
10 TCP connections within a second with a 10 initial cwnd, which isn't out of
line with what browsers often might do today while opening a web page, and
so at a roughly "not harmful" level suitable for a default.

(There's a little more context in the original message, but hopefully that
answers your question.)

> 2. 

I think moving the section is a little tricky.  I'm not sure the examples
make much sense without the context established in sections 2.1 and
2.2, but I can see why it might make sense to break up section 2 between
2.2 and 2.3, and to put the examples section in-between, and now that you
mention it, might improve the document.

What do you think of this structure?

Section 2 title "Relay Discovery Operation" -> "Relay Discovery Overview"
Section 2.1 title "Overview" -> "Basic Mechanics"
Section 3 "Examples" moved to section 2.3
Section 2 end after new section 2.3 (previously Section 3 examples)

New section 3 titled "Relay Discovery Overview"
Section 2.3 onward becomes section 3.1

Do you think that would be a worthwhile reordering?  Do you think it would
need any other changes?

I can see that having the examples before the more detailed sections about
relay discovery operation might improve the doc for those reading it in
order, I think that's a good point.  Thanks.

> And I saw that there is one normative requirement in the examples section

Good point, I will make the RECOMMENDED in 3.2.2 non-normative.

> no change based on the potential different location of the reply (than assumed

Now that you mention it, no, I don't think the congestion considerations
are different from non-DRIAD-capable AMT.

Here's proposed new text for the section, does this work for you?

OLD:
   Application implementors and network operators that use DRIAD-capable
   AMT gateways are advised to take precautions including monitoring of ...

NEW:
   Application implementors and network operators that use AMT gateways
   are advised to take precautions including monitoring of...

NEW: (new paragraph added to end of section)
   Section 4.1.4.2 of [RFC7450] and Section 6.1 of [RFC7450] provide
   some further considerations and advice about mitigating congestion
   risk.

> These should be references to RFC8305 (and not RFC8085).

Good catch, thanks for noticing!  Changed locally.

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