Re: [Masque] Zaheduzzaman Sarker's No Objection on draft-ietf-masque-connect-ip-09: (with COMMENT)

[David Schinazi <[e-mail]>]

Thanks for your review, Zahed! Responses inline.
David

On Thu, Apr 13, 2023 at 4:38 AM Zaheduzzaman Sarker via Datatracker <
[e-mail]> wrote:

> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-masque-connect-ip-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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for working on this specification.
>
> Thanks to Bob Briscoe for this TSVART review. Good to see that we are
> resolving
> the issues raised diligently and professionally. The work is in progress I
> think. This review and other reviews lead to some changes that to me would
> be
> nice to get some WG consensus call. I am sure my fellow AD and authors
> will do
> the right thing.
>

Definitely. We'll run the diff since WGLC by the WG.

I have some comments for the newly added performance consideration section -
>
> # It says -
>
>      Bursty traffic can often lead to temporally-correlated packet losses;
> in
>      turn, this can lead to suboptimal responses from congestion
> controllers in
>      protocols running inside the tunnel.To avoid this, endpoints SHOULD
> strive
>      to avoid increasing burstiness of IP traffic; they SHOULD NOT queue
>      packets in order to increase batching beyond the minimal amount
> required
>      to take advantage of hardware offloads.
>
>   I believe the suboptimal response is also true for the outer QUIC
> connection
>   as well. In that case, I am actually a bit confused by the term
> "endpoints",
>   is this supposed to only point to the endpoint generating IP traffic or
> does
>   it also refer to the tunneling endpoints? can we make that clear?
>

The guidance was specific to the tunnel and the endpoints refers to the IP
proxying endpoints, clarified in this commit:
https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/commit/a9dfd87c786aed5aaafac657d7047f65b2c4d3d0
While the guidance may apply to other protocols, I don't think this
document is the right place for that.

  The last sentence also creates the expectation that there is a minimal
>   batching amount to take the advantage of the hardware offloading. Does
> this
>   number easily available to the implementation of connect-ip? Have we
> done any
>   investigation on that? If this number is not available to the
> implementation
>   then it will be hard to follow the "SHOULD".
>

This was just a way of allowing implementations with knowledge of their
hardware to queue a little bit.
Implementations without that knowledge are told to not increase queuing.

# It says -
>
>       The outer HTTP connection MAY disable congestion control if it knows
> that
>       the inner packets belong to congestion-controlled connections.
>
>   How does it know?


That's intentionally left open-ended. Some deployments know because they
control the
implementation of all protocols involved.

Also what are the implications of nested congestion
>   control? yes, the tsv experts perhaps knows it by heart :-) but here we
> at
>   least need some reasoning based on the implications of the nested
> congestion
>   control for the advice and that is missing.
>

The implications of nested congestion control are an open research topic,
and
I'll note that these implications are quite contentious within the IETF, so
I'll let
TSVWG work on getting IETF consensus on what these implications are. For
a document like this, all we need is "there be dragons". The implementer can
only fine-tune such a system by measuring their own deployments.

# It says -
>
>     When the protocol running inside the tunnel uses loss recovery (e.g.,
> [TCP]
>     or [QUIC]), and the outer HTTP connection runs over TCP, the proxied
>     traffic will incur at least two nested loss recovery mechanisms.
>
>   This could also happen when outer HTTP connection run over QUIC and QUIC
>   Datagram is not used, right? or are we assuming that when the IP
> proxying is
>   done it always uses QUIC datagram?
>

Yes this could also happen if someone chose to send IP packets inside
DATAGRAM
capsules over HTTP/3, but we assume folks won't do that because of the
guidance
in this paragraph.