Subject: Re: [tcpm] Small nits in draft-ietf-tcpm-dctcp-02

From: Praveen Balasubramanian <[email-masked]>
Date: Sun, 13 Nov 2016 19:51:50 +0000

Thanks for the review Michael. Inline prefixed with >>.

-----Original Message-----
From: tcpm [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Sunday, October 23, 2016 6:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: [tcpm] Small nits in draft-ietf-tcpm-dctcp-02

Hi,

As we want to move forward the DCTCP document, I had (again) a look at the current version.

I run into three nits that should be simple to fix:

Section 1: "The queue must be short enough to absorb incast bursts without excessive packet loss." Is this "short" really the intended meaning here?

>> "short" indeed seems incorrect. Replacing with "long" in the next update. 

Figure 1: "m" is not introduced as far as I can see; this is only an editorial issue.

>> Adding a sentence to introduce m as the delayed ACK frequency. 

Section 8: The security considerations could probably comment on, or refer to, the statements on security concerns in Section 3.4 ("The security concerns addressed by both these RFCs might not apply in controlled environments like datacenters, and it might not be necessary to cater to both the presence of non-ECN servers."). This would result in a more comprehensive Section 8.

>> Removal of discussion of the security aspect in Section 3.4 makes sense. Left in the recommendation in this section and moved the security impact to Section 8.

Thanks

Michael
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 13 Nov 2016 23:31:45 +0000

Thanks Praveen. The updated document -03 addresses my review.

Michael

> From: Praveen Balasubramanian [mailto:[email-masked]]
> Sent: Sunday, November 13, 2016 8:52 PM
> To: Scharf, Michael (Nokia - DE); [email-masked]
> Subject: RE: Small nits in draft-ietf-tcpm-dctcp-02
> 
> Section 1: "The queue must be short enough to absorb incast bursts without
> excessive packet loss." Is this "short" really the intended meaning here?
> 
> Section 8: The security considerations could probably comment on, or refer to,
> the statements on security concerns in Section 3.4 ("The security concerns
> addressed by both these RFCs might not apply in controlled environments like
> datacenters, and it might not be necessary to cater to both the presence of
> non-ECN servers."). This would result in a more comprehensive Section 8.
> 
> >> Removal of discussion of the security aspect in Section 3.4 makes sense.
> Left in the recommendation in this section and moved the security impact to
> Section 8.
> 
> Thanks
> 
> Michael