Re: WGLC comments: draft-ietf-quic-recovery-29

[Ian Swett <[e-mail]>]

These comments were missed for a while, but are now in Issues #3992
<https://github.com/quicwg/base-drafts/issues/3992> and #3997
<https://github.com/quicwg/base-drafts/issues/3997>.

I don't yet fully understand the Initial Window issue(#3997) yet, so I'll
post some follow-up questions to the Issue.

On Wed, Jul 1, 2020 at 8:04 AM Jan Rüth <[e-mail]>
wrote:

> Hi,
>
> to add to Gorry’s review:
>
>
> > ISSUE:
> > In B.5,
> >           // Congestion avoidance.
> >           congestion_window += max_datagram_size * acked_packet.size
> >               / congestion_window
> > - is this calculation correct? I was thinking of what might happen when
> the PMTU is large and the sender generates a sequence of small packets…
> would this result in overestimating cwnd?
> >
>
> Moreover, acked_packet is not defined there.
>
> Only acked_packets (s at the end) is, and does >>size<< denote the number
> of packets (count might be a better name in this case) or their cumulative
> size?
>
> Also the part that Gorry quoted is performed within the loop, which would
> not lead to a linear increase I guess.
>
> I believe, if it refers to the actually acked bytes and the statement is
> outside of the loop, everything is fine and the packet size or a large PMTU
> does not affect this.
> (also the line length of the RFC made me look 5 times until I saw the
> “divided by cwnd”)
>
>
> > ISSUE:
> >
> > /Endpoints SHOULD use an initial congestion window of 10 times the
> maximum datagram size (max_datagram_size), limited to the larger of 14720
> or twice the maximum datagram size./
> >
> > - I would like to revist this. We talked in Montreal and at that time I
> understood the equivalence to TCP for the case where a large MSS was
> supported by the path, as per RFC6928. I have since revisited this topic
> and would like to suggest the present IETF advice for TCP is in fact wrong
> for the large initial MSS case, and that this draft should not perputate
> that mistake for QUIC. The issue comes when IW is initialiased for a path
> with a very large PMTU, but that PMTU is not in fact supported by the path.
>
> Do networks that support large MTUs usually also have more queue memory or
> why is this linked to the PMTU at all?
> Apart from this, I agree with Gorry here.
>
> Best
>  Jan
>
>