Al, thank you for the thoughtful explanation - I think I now understand a good step forward on both points and have written it up in the following PR:Detailed answers below.DavidOn Wed, Jun 1, 2022 at 3:57 PM MORTON JR., AL <acmorton@xxxxxxx> wrote:Thanks David, we’re getting closer.
see below,
Al
From: David Schinazi <dschinazi.ietf@xxxxxxxxx>
Sent: Wednesday, June 1, 2022 6:17 PM
To: MORTON JR., AL <acmorton@xxxxxxx>
Cc: ops-dir@xxxxxxxx; draft-ietf-masque-connect-udp.all@xxxxxxxx; last-call@xxxxxxxx; MASQUE <masque@xxxxxxxx>
Subject: Re: Opsdir last call review of draft-ietf-masque-connect-udp-12
Thanks, Al. Responses inline.
David
On Wed, Jun 1, 2022 at 9:31 AM MORTON JR., AL <acmorton@xxxxxxx> wrote:
Hi David,
please see some suggestions below, as requested.
Al
From: David Schinazi <dschinazi.ietf@xxxxxxxxx>
Sent: Tuesday, May 31, 2022 7:14 PM
To: MORTON JR., AL <acmorton@xxxxxxx>
Cc: ops-dir@xxxxxxxx; draft-ietf-masque-connect-udp.all@xxxxxxxx; last-call@xxxxxxxx; MASQUE <masque@xxxxxxxx>
Subject: Re: Opsdir last call review of draft-ietf-masque-connect-udp-12
Hi Al,
Thank you for the detailed review! I've written up a PR to address your comments:
More detailed comments inline.
Thanks,
David
On Tue, May 31, 2022 at 3:35 PM Al Morton via Datatracker <noreply@xxxxxxxx> wrote:
I found this paragraph confusing (which doesn't mean it is incorrect, just that
someone with limited background read the section 2 requirements list, all
MUSTs, and then the paragraph below, which seems to have a conflicting MUST
with the SHOULD and MAY that follows). Help readers like me understand the
options you are allowing here:
If the client detects that any of the requirements above are not met
by a URI Template, the client MUST reject its configuration and fail
the request without sending it to the UDP proxy. While clients
SHOULD validate the requirements above, some clients MAY use a
general-purpose URI Template implementation that lacks this specific
validation.
I see that Christer's GEN_ART review picked-up on this too (I looked after I
was done...).
Let's move this discussion point to the GENART thread to avoid duplication.
The fact that you both found it unclear is additional evidence that this could be
improved, but I'd love a textual suggestion if you have one.
[acm] I don’t have a GEN-ART message to reply to, but...
a wording that puts the SHOULD first, with the specific conditions when the SHOULD does not apply (client lacks the specific validation for the template in use?) might be a good start.
Then: Clients that can validate all URI Templete requirements MUST reject its configuration and fail
the request without sending it to the UDP proxy.
[acm] I doubt this is 100% solved, but it seems closer to me.
That doesn't quite match our intent though. The MUST is prefixed by an if clause.
Conceptually this means: "if you notice an issue you have to report it, but you
don't have to explicitly check for issues". What you propose would be "you should check
and if you check all possible requirements that you need to report findings" which is not
as strong.
[acm]
Thanks highlighting the IF, helps a lot.
Using your informal wording, I would say:
Your checking process SHOULD include all the requirements above, except when...(reasons why a client with limited capability might not perform all the requirement checks, which are all MUSTS IIRC)
and then
If you notice an issue, you must report it and reject the request.
This seems like the right order of ideas to me:
after presenting a list of MUSTS,
you SHOULD check them all,
and MUST report all exceptions found.
YMMV. I hope discussion with Christer yields something more useful.
I like your proposed ordering. How about the following text:Clients SHOULD validate the requirements above; however, clients MAY use a
general-purpose URI Template implementation that lacks this specific validation.
If a client detects that any of the requirements above are not met by a URI
Template, the client MUST reject its configuration and fail the request without
sending it to the UDP proxy.
In Section 5, there seems to be a possible operations issue for proxy operators:
Clients MAY optimistically start sending UDP packets in HTTP
Datagrams before receiving the response to its UDP proxying request.
However, implementors should note that such proxied packets may not
be processed by the UDP proxy if it responds to the request with a
failure, or if the proxied packets are received by the UDP proxy
before the request.
This seems like a good place to limit the amount of optimistic traffic, given
that the request is not yet accepted. (also, would the optimistic traffic use
Context ID zero?)
That's good advice, I've added the following to that paragraph:
If a UDP proxy receives such a proxied
packet before it has received the corresponding request, it SHALL either drop
that HTTP Datagram silently or buffer it temporarily (on the order of a round
trip). Additionally, UDP proxies that buffer such packets SHOULD limit the
amount they are willing to buffer to avoid memory exhaustion.[acm]
ok
And yes, proxied UDP uses context ID zero as specified by the paragraph above.
In
6. Performance Considerations
UDP proxies SHOULD strive to avoid increasing burstiness of UDP
traffic: they SHOULD NOT queue packets in order to increase batching.
This requirement is written qualitatively, so users might "know a violation if
they see it", but not hold the proxy system/operator to any specific
performance without providing more details here. Inter-packet delay variation
measurements on proxy ingress and egress would characterize increased
burstiness well. Another solution is s/SHOULD/should/ (I doubt some increased
burstiness will be avoidable, or enforceable.)
I think it makes sense for this requirement on proxies to be a normative SHOULD,
even though it's both qualitative and unenforceable by clients. It fits within the bounds
of what RFC 2119 mandates.
[acm]
So, authors are being asked to include the exceptional conditions that cause this requirement to SHOULD instead of a MUST now. If the reason is it's both qualitative and unenforceable by clients
Then add that phrase.
Can you elaborate on what your concern is? This is a SHOULD because we think
it's a good idea but that violating it won't prevent interoperability. That matches RFC 2119's
definition of SHOULD.
[acm]
I agree that minimizing added burstiness is a good thing.
I’m just saying that various IESG feedback on drafts I follow has asked for the explanation why a SHOULD is not a MUST. This isn’t a protocol requirement in the Performance Considerations section, it’s a recommendation to improve performance. And (from RFC2119)
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
doesn’t explicitly mention protocols or interop. Scott Bradner developed these terms for the BMWG, and the terms were first published in RFC 1944. Commenters have been asking authors to help the reader by providing “the valid reason to ignore” a SHOULD. And that’s what I’m passing along, that’s all.
Ah, I hadn't quite understood that - thank you. How about the following text:Bursty traffic can often lead to temporally correlated packet losses, which in
turn can lead to suboptimal responses from congestion controllers in protocols
running over UDP. To avoid this, UDP proxies SHOULD strive to avoid increasing
burstiness of UDP traffic: they SHOULD NOT queue packets in order to increase
batching.Thanks for the discussion, I’m not gonna stand on the RR tracks here, just trying to help.
This was definitely helpful, sorry it took me a few round trips to quite get it.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
