Re: [Last-Call] Opsdir last call review of draft-ietf-masque-connect-udp-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



And thanks Al for approving the GitHub PR! I've now merged it and will cut a new draft revision soon.
David

On Wed, Jun 1, 2022 at 4:20 PM David Schinazi <dschinazi.ietf@xxxxxxxxx> wrote:
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:
https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/pull/175/files
Detailed answers below.
David

On 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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux