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

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 13 Mar 2013 16:50:51 +0000

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-masked]>
 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
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Mar 2013 18:25:22 +0100 (CET)

On Wed, 13 Mar 2013, Fred Baker (fred) wrote:

> Folks. I posted the email I sent yesterday as a draft, for discussion. I 
> welcome comments, and if substantive comments are made, suggested text.

I voiced my opinion on the tsv-area meeting via jabber that AQM especially 
on low/medium bw links (up to 10-20 megabits/s) is needed and bufferbloat 
is a serious problem. As an employee of an operator, I would like to see 
documents in the line of RFC6204, ie basic requirements, for (in this 
case) AQM that I can use in procurement documents. Preferrably these would 
be implemented by kernel vendors (linux kernel and others) so the actual 
device vendor only needs to turn it on and perhaps set a few parameters 
(like communicate the link speed to the queue handler).

Coming back to the document at hand, reading 
draft-baker-tsvwg-aqm-recommendation-00.txt, I notice a few things. Am I 
misinterpreting text such as:

"Hence, network communication to the host regarding the moderation of
    its traffic flow SHOULD include both ECN and loss, with ECN being
    triggered earlier than loss."

... that it recommendeds that ECN traffic will be marked before non-ECN 
traffic is dropped? I believe desired behaviour is that ECN traffic is 
marked and non-ECN traffic is dropped at the exact same queue depth (or 
whatever mechanism causes packets to be dropped/marked).

Also, the documents seem to handle both host stack implementations and 
device queue management. Am I correct? Perhaps it would be preferable to 
have one document handling queueing (including the queue on the host 
towards its network interface (wifi/fixed/cellular etc), and another 
document talking about "TCP congestion control mechanisms"? Or this the 
document at hand trying to be an umbrella document for other documents?

Anyhow, I feel this (AQM/congestion) area of discussion is extremely 
important and it solves a real life problem that impacts a lot of people 
on the Internet as it works today. Personally I have routers with quite 
advanced AQM on my home connection (100/100 megabit/s) because I feel that 
FIFO even with WRED isn't good enough. However I understand that 
"fair-queue" uses a lot of CPU at these speeds, so it might not be 
feasable to do too advanced stuff at those speeds. However, at ADSL type 
accesses, for the uplink interface there is definitely a huge upside to 
have AQM.

When evaluating AQM the test scenarios should be quite advanced (I liked 
what I heard in ICCRG meeting yesterday) including VoIP, hundreds of TCP 
sessions using bittorrent, gaming (could be over TCP) etc. The ideal 
solution would be something that automatically allow at least per-user 
fairness in the upstream and something that perhaps sent ACKs and other 
smaller packets ahead of the queue of larger data packets.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: [email-masked]
Date: Wed, 13 Mar 2013 18:28:13 -0000

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

We need to be careful that we don't suggest not using ECN can gain advantage.

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.

Section 2 pt 4
- Agree and we also now have tunnel technologies considering ECN support,
so also these?

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.

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.

Gorry

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 13 Mar 2013 21:36:27 +0000

On Mar 13, 2013, at 1:25 PM, Mikael Abrahamsson <[email-masked]>
 wrote:

> I voiced my opinion on the tsv-area meeting via jabber that AQM especially on low/medium bw links (up to 10-20 megabits/s) is needed and bufferbloat is a serious problem. As an employee of an operator, I would like to see documents in the line of RFC6204, ie basic requirements, for (in this case) AQM that I can use in procurement documents. Preferrably these would be implemented by kernel vendors (linux kernel and others) so the actual device vendor only needs to turn it on and perhaps set a few parameters (like communicate the link speed to the queue handler).

> Coming back to the document at hand, reading draft-baker-tsvwg-aqm-recommendation-00.txt, I notice a few things. Am I misinterpreting text such as:
> 
> ... that it recommendeds that ECN traffic will be marked before non-ECN traffic is dropped? I believe desired behaviour is that ECN traffic is marked and non-ECN traffic is dropped at the exact same queue depth (or whatever mechanism causes packets to be dropped/marked).

Hmm. I probably didn't word that all that well.

My point is that at some level of congestion stress, we should mark ECN-capable traffic and drop non-ECN-capable traffic. At some higher level of stress, we should drop from all streams, ECN-capable or not. In general, I'd like to believe that ECN is effective in managing end-to-end throughput.

> Also, the documents seem to handle both host stack implementations and device queue management. Am I correct? Perhaps it would be preferable to have one document handling queueing (including the queue on the host towards its network interface (wifi/fixed/cellular etc), and another document talking about "TCP congestion control mechanisms"? Or this the document at hand trying to be an umbrella document for other documents?

One could argue for the separation. To my mind, though, they are firmly linked. Besides self-defense, the reason the network marks/drops traffic is to signal to TCP/SCTP. if that's the case, it seems like it's useful to say what that signal means to TCP/SCTP, and how we hope it might work.

> Anyhow, I feel this (AQM/congestion) area of discussion is extremely important and it solves a real life problem that impacts a lot of people on the Internet as it works today. Personally I have routers with quite advanced AQM on my home connection (100/100 megabit/s) because I feel that FIFO even with WRED isn't good enough. However I understand that "fair-queue" uses a lot of CPU at these speeds, so it might not be feasable to do too advanced stuff at those speeds. However, at ADSL type accesses, for the uplink interface there is definitely a huge upside to have AQM.

That depends on how FQ is implemented. The implementation I did in 1994 probably would have been high overhead. It has been minted by others, and I believe rewritten to be a calendar queue implementation. For that, I would not expect it was that much higher. I'll go take a look, though.

> When evaluating AQM the test scenarios should be quite advanced (I liked what I heard in ICCRG meeting yesterday) including VoIP, hundreds of TCP sessions using bittorrent, gaming (could be over TCP) etc. The ideal solution would be something that automatically allow at least per-user fairness in the upstream and something that perhaps sent ACKs and other smaller packets ahead of the queue of larger data packets.
> 
> --

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 13 Mar 2013 22:10:09 +0000

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

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

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

> - Agree and we also now have tunnel technologies considering ECN support,

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.

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

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

---

From: [email-masked]
Date: Wed, 13 Mar 2013 23:01:43 -0000

I think this is the kernel of something useful, a few comments in-line.

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

> 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 if that the incentive is correct - but you didn't
have space to explain the algorithm.

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

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Mar 2013 04:09:48 +0100 (CET)

On Wed, 13 Mar 2013, Fred Baker (fred) wrote:

> That depends on how FQ is implemented. The implementation I did in 1994 
> probably would have been high overhead. It has been minted by others, 
> and I believe rewritten to be a calendar queue implementation. For that, 
> I would not expect it was that much higher. I'll go take a look, though.

To be concrete, turning on fair-queue (and some other stuff to assure bw 
for certain tcp/port combinations) on a Cisco 7200 style device seems to 
give 2-3x CPU usage for the same traffic. This is with just 30-100 flows. 
This is in latest code available (15.2).

So since in my market we have gig speeds (we have low cost residential 
CPEs capable of moving ~600 megabits/s in a single tcp session), CPU 
impact of these queueing mechanisms is important.

And yes, I feel doing AQM at 100/100 speeds is still important, but here 
the limiting factor for speed might actually be the CPU of the CPE, so the 
queueing mechanism should preferrably be able to prioritize and gracefully 
handle the case where the links are not full but instead the CPE CPU is 
insufficient and that's what causing congestion/drops.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 14 Mar 2013 00:43:10 -0400

Hi,

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

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.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 14 Mar 2013 00:48:20 -0400

Clarification in line, sorry:

> And, even better: the more people use ECN, the more delay everybody gets.

… no, not everybody. The non-ECN users will still be doing fine.

Cheers,
Michael

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Mar 2013 06:07:37 +0100 (CET)

On Wed, 13 Mar 2013, Andrew McGregor wrote:

> A Netgear WNDR3800 (680MHz MIPS) can handle fq_codel on two flat out 
> 802.11n interfaces at the same time and still be very lightly loaded. 
> CPU is not a problem because fq_codel is a tiny fraction of the usage of 
> the firewall, connection tracking and 802.11 AP code, all of which are 
> necessary (in IPv4 the NAT also uses more CPU than fq_codel).

I'll have to look into what devices we're using and what CPUs they're 
using. The WNDR3800 seems to be a fairly high end device when I look at 
the price point.

However, the other part of your reply sounds hopeful. I read 
draft-nichols-tsvwg-codel-01 and I now realise that yes, it shouldn't be 
too cpu intensive as the hashing into bins sounds efficient on a 
per-packet level.

Would having multiple bin "trees" increase CPU usage a lot? I'm thinking 
of the use case where there are 10 computers in the home, of which one is 
doing 100 upload TCP sessions (bittorrent). If there was some mechanism 
that could identify a source IP address that caused most of the congestion 
and put them in a separate bin "tree" (basically each source IP would get 
its own set of bins, up to a maximum of perhaps 16 trees) and then these 
sets of bins would be emptied in a round-robin fashion (MDRR perhaps?). Or 
perhaps there would just be a "high volume speaker" tree and a "low volume 
speaker" tree, and it would be enough to just MDRR between these two 
trees. I realise we're now into "flow" territory which is exactly what 
Codel doesn't need to bother with currently, but just checking...

I saw in ICCRG that some testing was done with LEDBAT which I would 
imagine would help for the bittorrent case, but what about trying to 
achieve some of that without needing LEDBAT by using the above technique?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Mar 2013 06:11:20 +0100 (CET)

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 14 Mar 2013 10:54:20 +0000

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

I don't understand your comment. Fill me in please?

If I have a tail-drop queue, TCP using CUBIC or New Reno seeks to keep the queue full. If the queue has N positions (there are many ways to measure a queue, bear with this one for the purpose of the example), worst case delay approximates waiting for N messages, and general case delay is predicted by queuing theory to shoot for N when the link has 95% utilization or whatever.

With any AQM algorithm, the same queue will accept N messages in the event that it gets a burst, but will start marking/dropping at some point M significantly less than N, so that the queue depth tends to approximate M, not N. That's the whole point of any AQM algorithm. How M is chosen or predicted is of course different for various algorithms.

The pushback I generally hear about ECN is that people will mark traffic as ECN-capable in order to work around AQM algorithms signaling early; to make them signal later. I am told that people do abuse the EF code point in order to make their traffic go into a priority queue, so I can imagine people doing this as well.

What I am suggesting is that the AQM algorithm use the appropriate signal to make queue depth approximate M, whether than is ECN or loss depending on the traffic marking, and in the event of abuse do no worse than present it's-done-everywhere tail drop, in which the queue depth tends towards N.

M < N.

Remind me how saying that one will use ECN for ECN-capable traffic makes the average queue depth deeper? That makes no sense to me.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 14 Mar 2013 11:55:09 +0000

This will be my last note on the topic on tsvwg. I'd like to believe that by tomorrow we will have all joined aqm@.

> Remind me how saying that one will use ECN for ECN-capable traffic makes the average queue depth deeper? That makes no sense to me.

Following up on the comment about M and N. Let me show you some (old and low speed) slides that I use as examples in this class of discussion. It's not ECN vs loss, it's AQM vs tail-drop. However, since AQM-using-ECN and AQM-using-loss are examples of AQM, and the argument in the draft is to use both depending on the capabilities of the traffic, I think it's applicable.

    ftp://ftpeng.cisco.com/fred/dpreed/Bufferbloat_Masterclass.pdf

I'm looking at slides 11 and 12. Comments on the rest of the deck are interesting, but I'd suggest taking that private in order to not muddy this discussion.

The slides were pulled together as a simple and understandable example of what I said above about M and N. "AQM", in this case, is "RED"; other algorithms will display slightly different characteristics, but I assert that they will have the same basic behavior. The value and perhaps appearance of M will vary, but not the fact of it.

The test setup is two hosts talking across two low end routers connected with a 2 MBPS link. I could go faster; the charts would display timings appropriate to the line speeds and I would have to generate some multiple of the traffic to present the issue, but the structure of the behavior would be about the same. 

     +----+   +------+         +------+   +-----+
     |Left|   |Left  +---------+Right |   |Right|
     |Host|   |Router|         |Router|   |Host |
     +--+-+   +---+--+         +---+--+   +---+-+
        |         |                |          |
    ----+---------+---         ----+----------+---

On the "Left Host", I have a large file, large enough to take perhaps ten seconds to move to the "Right Host" in isolation. In one window on "Left", I run a ping -s to measure the RTT of traffic between the two hosts, and by extension the changing depth of the queue in "Left Router". In another window, I run a script. The script counts from one to fifteen. On each value, it simultaneously opens up that number of FTPs to copy said file to "Right Host". When the last FTP in the set completes, it waits a few seconds, rsh's to delete the now-unneeded copies from "Right", and goes on to the next value.

Afterwards, I did some simple calculations in Excel. I took successive and overlapping sets of ping measurements (ten, IIRC) and calculated the min, max, average (probably should have been median), and standard deviation of the set. I then plotted the values.

I ran the test twice, the difference being that I used RED or tail drop.

Slide 11 is the tail drop test. You see 15 bumps, measuring traffic from 1..15 FTPs moving said file in parallel. What is pretty obvious is that the variation in the queue is at the top of the queue; if N was five, we would be discussing variation around five; if it was five hundred, we would be discussing variation around five hundred. loss-based TCPs work Really Hard to fill the queue and keep it full, resulting in the potential queue depth being a predictor of end to end delay and variation in delay.

Slide 12 is the RED test. It's pretty obvious where I set min-thresh. I'm not, in this, suggesting a value for min-thresh, BTW; I set it somewhere to demonstrate that where I set it is the average queue depth in the scenario. You want it somewhere else, be my guest. What I observe is wider variation in queue depth, because I am using the configured depth of the queue to absorb bursts when they happen. But the average queue depth is at min-threshold. M, which is less than N.

I'll argue, and I think we probably generally agree, that the optimum target average queue depth is close to zero, and we'd like to use the buffer available to absorb and play out bursts when they happen. It would also be nice if the impact of AQM on the various data flows were more consistent, so that there was less variation in delay, and that might be true of some algorithms. But that's the target.

Coming back to ECN vs loss, ECN doesn't increase delay, it enables the same signal to be sent end to end, but sent more quickly and reliably (it is explicit and is known to be about congestion, as opposed to being implicit and possibly triggered by other factors). It targets the same mean queue depth. Signaling without losing traffic is better than losing traffic and calling that signaling, as the session completes more quickly and reliably and is then out of the way. I don't see the down side.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 14 Mar 2013 08:07:39 -0400

Hi,

Sorry in case I misunderstood. More below:

> With any AQM algorithm, the same queue will accept N messages in the event that it gets a burst, but will start marking/dropping at some point M significantly less than N, so that the queue depth t…

Up to here, I agree.

> The pushback I generally hear about ECN is that people will mark traffic as ECN-capable in order to work around AQM algorithms signaling early; to make them signal later. I am told that people do a…

Just for clarification, you mean: mark it but not react to it? (Which is possible, because the nonce isn't used…)

> What I am suggesting is that the AQM algorithm use the appropriate signal to make queue depth approximate M, whether than is ECN or loss depending on the traffic marking, and in the event of abuse…

Okay, now I understand where this is coming from.

>> algorithm is algorithm-dependent, however.

(Let's call the lower threshold M, and the higher one N.)
Reading this again, I now see that I probably just misunderstood you - apologies. I had somehow thought that you'd *always* drop non-ECN-capable traffic at M, as opposed to the randomized behavior given by an AQM. This would have meant that only ECN-capable traffic can make the queue grow beyond M.

I now see that this is surely not what you meant and agree that this makes sense - sorry.

Cheers,
Michael

---

From: "Black, David" <[email-masked]>
Date: Thu, 14 Mar 2013 09:04:02 -0400

One note on this one, although I probably will not join AQM, but instead watch
for useful results to emerge:

> Buffer depth > 50 ms = drop all traffic
> 

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-masked] [mailto:[email-masked]] On Behalf
> Of Mikael Abrahamsson
> Sent: Thursday, March 14, 2013 1:11 AM
> To: Michael Welzl
> Cc: [email-masked]
> Subject: Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-
> recommendation-00.txt
>