Re: [EXTERNAL] Re: WGLC review of draft-ietf-quic-recovery-29

[Ian Swett <[e-mail]>]

Thanks for the follow up comments and the excellent example Spencer.

Praveen, I agree that QUIC shouldn't require as many DC specific changes as
TCP, given it explicitly communicates max_ack_delay and there's no min RTO.

It seems there at least 4 options
1) Do nothing
2) Do nothing, but add a note that if you're on a managed network, some
requirements might not hold.
3) Change the MUST to a SHOULD
4) Use Neal's text or some variation thereof: "Implementations MUST either
use pacing or another method to limit such bursts. It is RECOMMENDED that
traffic over the public Internet limit bursts to the initial congestion
window; see Section 7.2."

I support softening this text some, given Linux today will burst well more
than 10 packets at once if the bandwidth is high enough.  Realistically, to
hit 1Gbps on a 5G network with QUIC, one might have to have bursts larger
than 10 packets, so I'm not sure this is only a DC issue.

I don't like the idea of saying you can change anything in the recovery doc
if you're on a managed network.  Obviously one can, but I'd be concerned
what might result.  Changing the MUST to a SHOULD is easy, but doesn't
provide any guidance on when it's ok to violate.  I'm hesitant to make a
distinction between public and private networks, partially because I do
think there are or will be valid cases for larger bursts on the public
internet.

I'm leaning towards saying you MUST limit bursts to IW unless the pacing
system can't provide enough sending opportunities to send at the rate
specified by the congestion controller.  Thoughts?

On Fri, Jul 17, 2020 at 12:41 PM Praveen Balasubramanian <
[e-mail]> wrote:

> AFAICT there is no RFC for TCP that limits burst sizes in general. I don’t
> think we need to special case Internet and DC networks. Changing the
> language from a MUST to a SHOULD is sufficient here. It leaves enough
> wiggle room for deployments and experimentation.
>
>
>
> I don’t see too many other changes needed in recovery draft for DC
> environment particularly now that there is no min rto. Jana, what other
> changes do you have in mind?
>
>
>
> *From:* Spencer Dawkins at IETF <[e-mail]>
> *Sent:* Friday, July 17, 2020 5:21 AM
> *To:* Jana Iyengar <[e-mail]>
> *Cc:* Ian Swett <[e-mail]>; Praveen Balasubramanian <
> [e-mail]>; Gorry Fairhurst <[e-mail]>; IETF QUIC
> WG <[e-mail]>; Neal Cardwell <[e-mail]>; Yuchung Cheng <
> [e-mail]>
> *Subject:* Re: [EXTERNAL] Re: WGLC review of draft-ietf-quic-recovery-29
>
>
>
> Hi, Jana,
>
>
>
> On Thu, Jul 16, 2020 at 8:30 PM Jana Iyengar <jri.ietf@gmail..com
> <[e-mail]>> wrote:
>
> At a high level, the recovery doc is _not_ written with DC environments in
> mind. We can make that clear in the document, if that helps. There are
> other things as well that won't work well in a DC environment, and I
> imagine a separate doc would be helpful here that specifies how QUIC ought
> to be tuned for DCs.
>
>
>
> Two things.
>
>
>
> My response to Ian was just about the history of what TSV has come to
> expect for encapsulation protocol behaviors in the past half-dozen years
> ("if you are doing stuff that's not safe on an unmanaged network, this is
> what you should do; if you're doing the same thing on a managed network,
> this is what you can probably get away with, and please point to your
> circuit breaker functionality in case what you're doing turns out to be a
> Really Bad Idea" - paraphrasing over a lot of subtilty).
>
>
>
> Those documents tended to have both cases in a single document, along with
> the rest of the encapsulation protocol, in many cases because the
> "unmanaged networks" considerations were being added to a single document
> that already described "managed networks" considerations.
>
>
>
> Pretty much every conversation I was involved in at QUIC charter time
> assumed that we would want to swap recovery functionality in and out over
> time without reopening draft-ietf-quic-transport, so having a separate
> recovery document was the right thing to do.
>
>
>
> Because QUIC already has a separate "safe for unmanaged networks" recovery
> document, I think putting other recovery strategies in separate documents
> is a fine plan.
>
>
>
> Does that make sense?
>
>
>
> Best,
>
>
>
> Spencer
>
>
>
> On Thu, Jul 16, 2020 at 2:18 PM Spencer Dawkins at IETF <
> [e-mail] <spencerdawkins.ietf@gmail..com>> wrote:
>
> Hi, Ian,
>
>
>
> On Thu, Jul 16, 2020 at 2:22 PM Ian Swett <ianswett=
> [e-mail]> wrote:
>
> Thanks for the comments, I filed #3918
> <https://github..com/quicwg/base-drafts/issues/3918> and #3919
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3919&data=02%7C01%7Cpravb%40microsoft.com%7C3aec4cda750d49b8a7ef08d82a4bf551%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305853016570346&sdata=akzKemBS1w2ASNuqfhCfXjV0PjkmtWJnD3NKm%2FWL%2BJg%3D&reserved=0>
>
>
>
>
> For my background, are you aware other transport RFCs have normative
> statements that only apply to the public internet?
>
>
>
> Tunnels are transport, right? :-)
>
>
>
> The earliest RFC I was involved with, that made distinctions about what
> you can get away with on the public internet versus in a managed network,
> was https://tools.ietf.org/html/rfc7510#section-5
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7510%23section-5&data=02%7C01%7Cpravb%40microsoft.com%7C3aec4cda750d49b8a7ef08d82a4bf551%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305853016580341&sdata=yS2XCONR3lZx10mfajWbppCDytE2DM1Y5Qc4r5uIyv0%3D&reserved=0>.
> This was negotiated after a fairly vigorous back-and-forth between
> transport people and non-transport people during IETF Last Call.
>
>
>
> We put together a design team with a few people to try to work through
> this for the myriad other protocols that people wanted to tunnel over UDP,
> once and for all.
>
>
>
> https://tools.ietf.org/html/rfc8084
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8084&data=02%7C01%7Cpravb%40microsoft.com%7C3aec4cda750d49b8a7ef08d82a4bf551%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305853016580341&sdata=GOTJobJC74eepsoltLYDssFu4%2FE8M1C97m173JHwdH0%3D&reserved=0>
> was published as a BCP.
>
>
>
> I may be forgetting other stuff, of course.
>
>
>
> Best,
>
>
>
> Spencer
>
>
>
> Also, if you're that well buffered and the bursts are that large, do you
> still start with IW10, or do you start with a larger window?
>
>
>
> Thanks, Ian
>
>