3 ms·

Is this the same as the SIGCOMM '10 DCTCP paper [0]? I see that the author lists of both strongly draw from Microsoft, but there's no overlap otherwise. If so,

by vitus 9y ago

Is this the same as the SIGCOMM '10 DCTCP paper [0]? I see that the author lists of both strongly draw from Microsoft, but there's no overlap otherwise. If so, what's changed in the past 7 years? Why publish the RFC now, especially since it's not on track to become an Internet standard? Something called DCTCP has been in the Linux kernel since 2014 [1]; that commit even cites what looks like an earlier draft of this RFC that dates back to 2014, although that was on the standards track back then [2]. Why was that effort seemingly abandoned? [0] https://people.csail.mit.edu/alizadeh/papers/dctcp-sigcomm10.pdf https://people.csail.mit.edu/alizadeh/papers/dctcp-sigcomm10... [1] https://git.kernel.org/linus/e3118e8359bb7c59555aca60c725106e6d78c5ce https://git.kernel.org/linus/e3118e8359bb7c59555aca60c725106... [2] https://tools.ietf.org/html/draft-bensley-tcpm-dctcp-00 https://tools.ietf.org/html/draft-bensley-tcpm-dctcp-00

otterley 9y ago
The RFC clearly states: > This document describes DCTCP as implemented in Microsoft Windows Server 2012 [WINDOWS]. The Linux [LINUX] and FreeBSD [FREEBSD] operating systems have also implemented support for DCTCP in a way that is believed to follow this document. Deployment experiences with DCTCP have been documented in [MORGANSTANLEY]. > Why publish the RFC now, especially since it's not on track to become an Internet standard? Presumably it's to guide future implementors who wish to attain compatibility with the existing implementations.
cryptonector 9y ago
> Why publish the RFC now, especially since it's not on track to become an Internet standard? One might ask why ever publish RFCs that are not on the Standards Track? But that seems a bit silly. We have Experimental, Information, BCP, and Standards tracks for a reason. As to why publish now? Most likely because the authors finally got the energy to reach the finish line recently. It does happen that some Internet-Drafts take years to reach the RFC-Editor queue. Taking a long time is not fatal.

by vitus 9y ago

otterley 9y ago

The RFC clearly states: > This document describes DCTCP as implemented in Microsoft Windows Server 2012 [WINDOWS]. The Linux [LINUX] and FreeBSD [FREEBSD] operating systems have also implemented support for DCTCP in a way that is believed to follow this document. Deployment experiences with DCTCP have been documented in [MORGANSTANLEY]. > Why publish the RFC now, especially since it's not on track to become an Internet standard? Presumably it's to guide future implementors who wish to attain compatibility with the existing implementations.

cryptonector 9y ago

> Why publish the RFC now, especially since it's not on track to become an Internet standard? One might ask why ever publish RFCs that are not on the Standards Track? But that seems a bit silly. We have Experimental, Information, BCP, and Standards tracks for a reason. As to why publish now? Most likely because the authors finally got the energy to reach the finish line recently. It does happen that some Internet-Drafts take years to reach the RFC-Editor queue. Taking a long time is not fatal.