One note on this one, although I probably will not join AQM, but instead watch for useful results to emerge:
> >>> As I just said to Mikael, I don't think I worded that one well. I'm > >>> envisaging two thresholds, testing two stress levels. It a lower one, one > >>> marks ECN-capable traffic and drops non-ECN-capable traffic; at the higher > >>> one, one drops from all traffic. What "threshold" means in a given > >>> algorithm is algorithm-dependent, however. > > > > Great, I turn on ECN, and that gives me more delay, just what I want! > > And, even better: the more people use ECN, the more delay everybody gets. > > Could you please elaborate on how you came to this conclusion? > > > Seriously, I see the incentive idea behind this two-level marking idea, > > but one has to carefully consider the increased delay vs. gained > > throughput trade-off in such a scheme. > > Why would it be better to drop the packet than to ECN-mark it? > > Concrete example: > > Buffer depth > 30 ms = mark ECN traffic, drop non-ECN traffic > Buffer depth > 50 ms = drop all traffic > > The congestion signal to TCP at buffer depth 30 ms is the same for both > ECN and non-ECN traffic, so I don't see how this would increase the delay? I assume a simple tail-drop example was used to make the point. Proportional random marking/dropping should be used for reasons that we're all familiar with. Despite that, this is an example of how ECN is supposed to be configured - CE is supposed to tell the receiver "I would have dropped this packet, but I'm sending it to you instead as a favor - tell the sender to adjust its transmission behavior as if the packet had been dropped, but there's no need to retransmit this packet." Thanks, --David (RFC 3168 co-author) > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Mikael Abrahamsson > Sent: Thursday, March 14, 2013 1:11 AM > To: Michael Welzl > Cc: [email protected] > Subject: Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm- > recommendation-00.txt > > On Thu, 14 Mar 2013, Michael Welzl wrote: > > >>> As I just said to Mikael, I don't think I worded that one well. I'm > >>> envisaging two thresholds, testing two stress levels. It a lower one, one > >>> marks ECN-capable traffic and drops non-ECN-capable traffic; at the higher > >>> one, one drops from all traffic. What "threshold" means in a given > >>> algorithm is algorithm-dependent, however. > > > > Great, I turn on ECN, and that gives me more delay, just what I want! > > And, even better: the more people use ECN, the more delay everybody gets. > > Could you please elaborate on how you came to this conclusion? > > > Seriously, I see the incentive idea behind this two-level marking idea, > > but one has to carefully consider the increased delay vs. gained > > throughput trade-off in such a scheme. > > Why would it be better to drop the packet than to ECN-mark it? > > Concrete example: > > Buffer depth > 30 ms = mark ECN traffic, drop non-ECN traffic > Buffer depth > 50 ms = drop all draffic > > The congestion signal to TCP at buffer depth 30 ms is the same for both > ECN and non-ECN traffic, so I don't see how this would increase the delay? > > -- > Mikael Abrahamsson email: [email protected]
