I think this is the kernel of something useful, a few comments in-line. > On Mar 13, 2013, at 2:28 PM, <[email protected]> > wrote: > >> Fred, >> >> Comments below: >> >> Section 2, pt 2 >> "Deployed AQM SHOULD use ECN as well as loss, and set thresholds >> to mark traffic earlier than it is lost." >> - This is not clear, I agree SHOULD use ECN for ECT traffic, of course. >> - I'm not sure about threshold question that sets ECN drop before ECN >> loss > > 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. > That's what I thought you intended.
>> - I like the idea for various reasons (I'm not expanding that here), but >> this isn't what I understand as the current recommended TCP ECN reaction >> - >> which reacts to CE in the same way as loss? > > Well, 3168 says that TCP should respond in the same way it responds to > loss. By that, what they mean is that it reduces cwnd, and if in > slow-start, exit slow-start. The other thing it does to respond to loss is > to retransmit a message. There is obviously no need to retransmit, but it > should indeed play with cwnd in some way. > Agree > How it responds will be specific to the congestion control algorithm, > though. With newreno, it might set cwnd to 1 or to the initial value, or > perhaps halve it. > 1/2 would be ok > With CUBIC, IIRC, it reduces it by a smaller fraction. > With CalTech FAST, which is a delay-based model and tunes toward the knee, > I could imagine that instead of literally reducing cwnd (if you're at the > knee, why would you do that?) you might recalculate the current mean RTT. > >> We need to be careful that we don't suggest not using ECN can gain >> advantage. > > Did I say that? > We need to be careful if that the incentive is correct - but you didn't have space to explain the algorithm. >> Section 2 pt 3 >> - Again I agree, but not sure we can say this as a BCP requirement? I >> think we should think about how best to present this. > > 2.3. AQM algorithms deployed SHOULD NOT require operational tuning > > There are algorithms that don't require tuning. I'm suggesting we use one. > If these really are shown to work on all scenarios... Then that could be ok, but I am not sure yet alg work in all places. >> Section 2 pt 4 >> - Agree and we also now have tunnel technologies considering ECN >> support, >> so also these? > > 2.4. AQM algorithms deployed SHOULD be effective on all common > Internet traffic > > We want to follow the rules for remarking traffic; I believe that's RFC > 2983. > >> Section 2 pt 5 >> - Nice, but not not possible - so TCP without ECN *IS* going to cause >> loss and delay if it shares the same congested queue. The idea of >> defining >> guidance on what to expect here is also good, and maybe a significant >> step >> to getting a better understanding. > > 2.5. TCP and SCTP congestion control algorithms SHOULD > maximize their use of available bandwidth without > incurring loss or undue round trip delay > > I'm not quite as pessimistic about the possibility here. We actually do > have congestion control algorithms that tune to a point approximating the > knee, and at least one that will co-exist with a loss-based model > effectively (CAIA CDG). Note that I'm not dying to get to the knee, > although that would be nice; the point is to not hit the cliff. Once the > window advances to/beyond the knee, we are using the available bandwidth > in its entirety; increasing cwnd after that point merely increases delay > and the probability of loss, not throughput rate. > >> I note that RFC 2309 does recommend RED but importantly it did not >> motivate it in the way that now makes AQM an imperative. It also largely >> pre-dated ECN and certainly the experience in ECN implementation. > > Hmm. OK, then maybe we do need to re-do 2309. That was my first instinct > when Wesley and I first chatted about this in mail, and I thought I would > try simply building on it. I'll take a gander at that. > >> Gorry >> >>> Folks. I posted the email I sent yesterday as a draft, for discussion. >>> I >>> welcome comments, and if substantive comments are made, suggested text. >>> >>> >>> On Mar 13, 2013, at 12:48 PM, <[email protected]> >>> wrote: >>> >>>> >>>> A new version of I-D, draft-baker-tsvwg-aqm-recommendation-00.txt >>>> has been successfully submitted by Fred Baker and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-baker-tsvwg-aqm-recommendation >>>> Revision: 00 >>>> Title: IETF Recommendations Regarding Active Queue Management >>>> Creation date: 2013-03-13 >>>> Group: Individual Submission >>>> Number of pages: 7 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-baker-tsvwg-aqm-recommendation-00.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-baker-tsvwg-aqm-recommendation >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-baker-tsvwg-aqm-recommendation-00 >>>> >>>> >>>> Abstract: >>>> Fifteen years after the IAB issued its recommendations regarding >>>> congestion control in RFC 2309, a major issue in the community is the >>>> issue that RFC addresses: Buffer bloat. It may be time to update the >>>> recommendation. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> >> >> >
