On Sat, 28 Mar 2015, Scheffenegger, Richard wrote:
David,
Perhaps you would care to provide some text to address the misconception that
you pointed out? (To wait for a 100% fix as a 90% fix appears much less
appealing, while the current state of art is at 0%)
Ok, you put me on the spot :-)
, think twice to drop:
draft-ietf-aqm-ecn-benefits-02
On Fri, 27 Mar 2015, Scheffenegger, Richard wrote:
Hi David,
- low latency AND high throughput (compared to low latency OR high
throughput for drop based congestion controllers)
I think that you are overstating things when you say
David,
Perhaps you would care to provide some text to address the misconception that
you pointed out? (To wait for a 100% fix as a 90% fix appears much less
appealing, while the current state of art is at 0%)
If you think that aqm-recommendations is not strogly enough worded. I think
this
On Fri, 27 Mar 2015, De Schepper, Koen (Koen) wrote:
Hi all,
Agreed that there implementations should not be described. Also agree that we
should describe all the benefits of using ECN, so I propose to reformulate
something as follows:
ECN allows to introduce and deploy state of the art ECN
On Fri, 27 Mar 2015, KK wrote:
The discussion about adding buffers and the impact of buffers should be
considered relative to the time scales when congestion occurs and when it
is relieved by the dynamics of the end-system protocols. The reason we
have buffering is to handle transients at the
The discussion about adding buffers and the impact of buffers should be
considered relative to the time scales when congestion occurs and when it
is relieved by the dynamics of the end-system protocols. The reason we
have buffering is to handle transients at the points where there is a
mismatch in
Hi,
Below:
On 25. mar. 2015, at 13.12, De Schepper, Koen (Koen)
koen.de_schep...@alcatel-lucent.com wrote:
Hi all,
Related to DCTCP and different (more) marking ECN than dropping (let's call
it ECN++ in this mail), the talk I gave in iccrg (Data Center to the Home)
shows that it is
Hi all,
Related to DCTCP and different (more) marking ECN than dropping (let's call it
ECN++ in this mail), the talk I gave in iccrg (Data Center to the Home) shows
that it is possible to have fairness between ECN++ flows (DCTCP, Relentless
TCP, Scalable TCP, ...) and drop based Reno/Cubic
