Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt

["Fred Baker (fred)" <[e-mail]>]

On Mar 13, 2013, at 2:28 PM, <[e-mail]>
 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.

> - 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.

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. 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?

> 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.

> 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, <[e-mail]>
>> 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
>>> 
>> 
> 
>