Subject: [iccrg] about draft-balasubramanian-iccrg-ledbatplusplus-01

From: MARCELO GABRIEL BAGNULO BRAUN <[email-masked]>
Date: Wed, 6 Nov 2019 16:14:33 +0100

Hi,
I think this version is much clearer than the previous one, thanks for that.
Some additional comments.

The document is proposed to be Informational. I wonder if it is not
more appropriate to make it experimental. I guess it depends what you
are after. If you merely want to document the microsoft
implementation, i guess informational makes sense, but if you wish it
to be a product of the RG, then probably you can go for experimental.
If you decide to go for informational, I guess you can drop the
RFC2119 terminology and the related paragraph.

Regarding sections 4.1, 4.2 and 4.3, I think that the readability of
the mechanisms can be improved with some rearrangement. I mean, in
section 4.1 you use the GAIN, but the GAIN is not introduced until
section 4.2.
In section 4.2 you talk about the increase, but the actual increase
formula is presented in section 4.3 which talks about the decrease.
I would probably start by defining the GAIN, then presenting the slow
start, then the increase and then decrease.
Also, in the Slow start section, you refer to the ssthresh, but the
way this is computed is only presented in section 4.4. Probably it
would make sense to group all slow start (initial and periodic) in a
single section.

You probably should explicitly state the units in which the
expressions are expressed (in particular, the GAIN is added to the
window, I guess it is expressed in MSS).

I am missing from the draft the response to packet losses. I assume it
is the same a New Reno, but probably it is worth stating it.

Regards, marcelo

-- 
MARCELO GABRIEL BAGNULO BRAUN
Universidad Carlos III de Madrid

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 6 Nov 2019 17:13:43 +0000

Thanks Marcelo. I'd first like to ask the iccrg working group about adopting this document. The working group should then discuss if it makes sense to publish as informational or experimental. Jana touched upon publishing documents from iccrg in the last WG meeting but we didn’t do an adoption call. 

Rest inline prefixed by [praveen]. 

Thanks

-----Original Message-----
From: MARCELO GABRIEL BAGNULO BRAUN <[email-masked]> 
Sent: Wednesday, November 6, 2019 7:15 AM
To: iccrg IRTF list <[email-masked]>; Praveen Balasubramanian <[email-masked]>
Subject: about draft-balasubramanian-iccrg-ledbatplusplus-01

Hi,

The document is proposed to be Informational. I wonder if it is not more appropriate to make it experimental. I guess it depends what you are after. If you merely want to document the microsoft implementation, i guess informational makes sense, but if you wish it to be a product of the RG, then probably you can go for experimental.
If you decide to go for informational, I guess you can drop the
RFC2119 terminology and the related paragraph.

Regarding sections 4.1, 4.2 and 4.3, I think that the readability of the mechanisms can be improved with some rearrangement. I mean, in section 4.1 you use the GAIN, but the GAIN is not introduced until section 4.2.
In section 4.2 you talk about the increase, but the actual increase formula is presented in section 4.3 which talks about the decrease.
I would probably start by defining the GAIN, then presenting the slow start, then the increase and then decrease.

[praveen] I agree that readability can be improved. I moved around the sections in 01 to address this but certainly needs more work.

Also, in the Slow start section, you refer to the ssthresh, but the way this is computed is only presented in section 4.4. Probably it would make sense to group all slow start (initial and periodic) in a single section.

[praveen] Agreed. I plan to add pseudo code as well. 

You probably should explicitly state the units in which the expressions are expressed (in particular, the GAIN is added to the window, I guess it is expressed in MSS).

[praveen] Yes currently the formulas are not based on bytes ACKed.

I am missing from the draft the response to packet losses. I assume it is the same a New Reno, but probably it is worth stating it.

[praveen] "LEDBAT reacts  to packet losses and other congestion signals in the same way as  standard TCP." I general we have only covered modifications to LEDBAT so the document is currently not self-contained and is an extension to LEDBAT. The pseudo code will certainly cover this and I'll consider adding text too.

Regards, marcelo