Thanks Neal,
I’m good with the updated version.
Thanks,
Daniele
Daniele
From: Neal Cardwell <ncardwell@xxxxxxxxxx>
Sent: Wednesday, June 11, 2025 8:48:26 PM
To: Daniele Ceccarelli (dceccare) <dceccare@xxxxxxxxx>
Cc: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>; draft-ietf-tcpm-prr-rfc6937bis.all@xxxxxxxx <draft-ietf-tcpm-prr-rfc6937bis.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; tcpm@xxxxxxxx <tcpm@xxxxxxxx>; Yuchung Cheng <ycheng@xxxxxxxxxx>; Matt Mathis <ietf@xxxxxxxxxxxxxx>; Nandita Dukkipati <nanditad@xxxxxxxxxx>
Subject: Re: draft-ietf-tcpm-prr-rfc6937bis-16 ietf last call Opsdir review
Sent: Wednesday, June 11, 2025 8:48:26 PM
To: Daniele Ceccarelli (dceccare) <dceccare@xxxxxxxxx>
Cc: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>; draft-ietf-tcpm-prr-rfc6937bis.all@xxxxxxxx <draft-ietf-tcpm-prr-rfc6937bis.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; tcpm@xxxxxxxx <tcpm@xxxxxxxx>; Yuchung Cheng <ycheng@xxxxxxxxxx>; Matt Mathis <ietf@xxxxxxxxxxxxxx>; Nandita Dukkipati <nanditad@xxxxxxxxxx>
Subject: Re: draft-ietf-tcpm-prr-rfc6937bis-16 ietf last call Opsdir review
Hi Daniele,
Thank you for your very helpful review! I have incorporated your
feedback into a new revision of the draft (rev 18):
There is an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tcpm-prr-rfc6937bis-18.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-prr-rfc6937bis-18
Detailed responses in-line below.
On Wed, Jun 4, 2025 at 3:40 AM Daniele Ceccarelli via Datatracker
<noreply@xxxxxxxx> wrote:
>
> Document: draft-ietf-tcpm-prr-rfc6937bis
> Title: Proportional Rate Reduction for TCP
> Reviewer: Daniele Ceccarelli
> Review result: Ready
>
> Hello,
> I am the assigned OPS-DIR reviewer for this draft.
> Document: draft-ietf-tcpm-prr-rfc6937bis-16
> Reviewer: Daniele Ceccarelli
> Review Date: 2025-06-04
> IETF LC End Date: 2025-06-06
>
> Summary: Almost Ready
> Major Concerns: None
> Minor Concerns: Improve readability
>
> The draft is well written and understandable also to a someone that doesn't
> have a deep knowledge of TCP. While it's ok to have the abstract extremely
> straight to the point without major explanations, i found the intro pretty hard
> to understand. Things became more clear when reaching the background section.
> Probably it would be good idea to join the 2 sections into a single one, which
> could be called intro and backgorund, or simply intro (because in the end the
> scope of the intro is to provide a background).
Good idea! Done. I've integrated the background material into the
introduction, trying to ensure that each passage only uses terms and
concepts already described by the earlier text.
> I would also anticipate the definitions section (section 7) higher in the
> document as that's a pre-requirement to understand what is being described.
> E.g. SDN.UNA is described in section 5 and the definition is only provided in
> section 7.
Good point. In revision 16 we moved the definitions section higher in
the document. The "Definitions" section is now after the
"Introduction" and "Conventions" sections, and before the "Changes
Relative to RFC 6937" section. I have attempted to ensure that the
"Introduction" section defines key terms as it first uses them, like
inflight, cwnd, and ssthresh. I don't think the Intro section depends
on any of the other terms, but please let me know if I missed
something.
> In section 4 the draft says: " This document describes two slightly different
> Reduction Bound algorithms", but in the rest of the text the split between 2
> algorithms is lost, in fact section 8 speaks about 1 algorithm.
Good point. In revision 18 I have tried to clear this up by not
describing the Reduction Bound approaches as separate "Reduction Bound
algorithms" but simply as "Reduction Bounds". In revision 16 we
already had the simpler "Reduction Bounds" phrasing in four spots, so
this makes the text more self-consistent.
> I really appreciate the example section, very clear.
Thanks!
Please let us know if you have any more feedback.
Thanks!
neal
> Thanks
> Daniele
>
>
Thank you for your very helpful review! I have incorporated your
feedback into a new revision of the draft (rev 18):
There is an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tcpm-prr-rfc6937bis-18.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-prr-rfc6937bis-18
Detailed responses in-line below.
On Wed, Jun 4, 2025 at 3:40 AM Daniele Ceccarelli via Datatracker
<noreply@xxxxxxxx> wrote:
>
> Document: draft-ietf-tcpm-prr-rfc6937bis
> Title: Proportional Rate Reduction for TCP
> Reviewer: Daniele Ceccarelli
> Review result: Ready
>
> Hello,
> I am the assigned OPS-DIR reviewer for this draft.
> Document: draft-ietf-tcpm-prr-rfc6937bis-16
> Reviewer: Daniele Ceccarelli
> Review Date: 2025-06-04
> IETF LC End Date: 2025-06-06
>
> Summary: Almost Ready
> Major Concerns: None
> Minor Concerns: Improve readability
>
> The draft is well written and understandable also to a someone that doesn't
> have a deep knowledge of TCP. While it's ok to have the abstract extremely
> straight to the point without major explanations, i found the intro pretty hard
> to understand. Things became more clear when reaching the background section.
> Probably it would be good idea to join the 2 sections into a single one, which
> could be called intro and backgorund, or simply intro (because in the end the
> scope of the intro is to provide a background).
Good idea! Done. I've integrated the background material into the
introduction, trying to ensure that each passage only uses terms and
concepts already described by the earlier text.
> I would also anticipate the definitions section (section 7) higher in the
> document as that's a pre-requirement to understand what is being described.
> E.g. SDN.UNA is described in section 5 and the definition is only provided in
> section 7.
Good point. In revision 16 we moved the definitions section higher in
the document. The "Definitions" section is now after the
"Introduction" and "Conventions" sections, and before the "Changes
Relative to RFC 6937" section. I have attempted to ensure that the
"Introduction" section defines key terms as it first uses them, like
inflight, cwnd, and ssthresh. I don't think the Intro section depends
on any of the other terms, but please let me know if I missed
something.
> In section 4 the draft says: " This document describes two slightly different
> Reduction Bound algorithms", but in the rest of the text the split between 2
> algorithms is lost, in fact section 8 speaks about 1 algorithm.
Good point. In revision 18 I have tried to clear this up by not
describing the Reduction Bound approaches as separate "Reduction Bound
algorithms" but simply as "Reduction Bounds". In revision 16 we
already had the simpler "Reduction Bounds" phrasing in four spots, so
this makes the text more self-consistent.
> I really appreciate the example section, very clear.
Thanks!
Please let us know if you have any more feedback.
Thanks!
neal
> Thanks
> Daniele
>
>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
