> On 10. nov. 2014, at 14.08, Fred Baker (fred) <[email protected]> wrote: > > > On Nov 10, 2014, at 1:20 PM, <[email protected]> <[email protected]> > wrote: > >> While I agree that the ECN benefits draft does not motivate any mechanism >> for ECN. I think the draft, should simply echo the BCP AQM Recommendation >> on ECN deployment: >> >> "Deployed AQM algorithms SHOULD support Explicit Congestion Notification >> (ECN) as well as loss to signal congestion to endpoints." and refer to >> that BCP. > > Dumb question for you. > > Where I was a little concerned, and raised a question from the mike, was the > statement that "AQM algorithms MAY describe their use with ECN”. My concern > is for interoperability.
I think that’s a mix-up: you spoke up for the ECN part of draft-ietf-aqm-eval-guidelines while Gorry’s comment was about draft-ietf-aqm-ecn-benefits - right? Cheers, Michael > > My sense with any AQM algorithm is the it should take signals (marks or > drops) coming at a certain rate to manage a given TCP session or combination > of TCP sessions to maximize throughput while minimizing latency. There is > some question of the distribution of the signals; CUBIC will respond > differently to having three successive packets dropped than having three > packets dropped an RTT or two apart. I wonder whether what we really want is > some kind of draft that describes the pattern and rate we want to achieve, > including observations like Bob’s desire to have the mark threshold differ > from the drop threshold. What is of value in the algorithm descriptions is > how the algorithm should be parameterized to achieve that common goal, not > different goals. > > Am I making sense? > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
