Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #2

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

On Apr 30, 2013, at 9:29 AM, Wesley Eddy <[e-mail]>
 wrote:

> On 4/29/2013 10:00 AM, Fred Baker (fred) wrote:
>> Do we generally agree with the recommendation of http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.2? This is the question of signaling to an endpoint using both dropping and ECN.
>> 
> 
> I think there are two recommendations embedded at the end of the
> section:
> 
> """
>   Hence, network communication to the host regarding the moderation of
>   its traffic flow SHOULD use an AQM algorithm to determine which
>   packets it should affect, and then implement that effect by marking
>   ECN-capable traffic "Congestion Experienced (CE)" or dropping non-
>   ECN-capable traffic.
> 
>   Due to the possibility of abuse, the queue must also impose an upper
>   bound, so that even ECN-capable traffic experiences tail-drop if
>   necessary; this possibility, while equipment must design for the end
>   case, should in theory be very uncommon.
> """
> 
> I'm basically good with both.
> 
> The second part (imposing an upper bound) might be worth expanding a
> bit.  I don't know what a reasonable upper bound is, for failing into
> a tail-drop mode, and it smells like another knob to be configured,
> which we are hoping to avoid :).
> 
> So, there is a can of worms here.  Should the threshold be configurable?
> Should it be based on some margin computed from the queue depth, link
> rate, etc?  What should the defaults be?  What types of experiments
> would we do in order to test sensitivity of this parameter and tune it?
> 
> I think all of these depend a bit on how the specific AQM works, and
> it's tough to say much concrete about it.
> 
> -- 
> Wes Eddy
> MTI Systems

Hmm. Maybe I should separate them into separate recommendations.

Yes, I think ECN has the built-in possibility of an end system using the flag to gain what it thinks is some variation on preference - it can get one more packet into a queue than it would if it didn't advertise an ECN capability, but it doesn't actually implement RFC 3168 etc. At some point, one has to drop even ECN-capable traffic. Not for AQM reasons; for defensive reasons.

I have, and dare I say "we have", observed several implementations that have tried the approach of bending the rules to gain preference. BitTorrent did so by having multiple parallel aggressive TCP-like connections; we all know the outcome of that - multiple connections is fine, but bulldozing networks is a good way to get yourself bulldozed. One TCP implementation I know of did away with slow start and congestion control altogether. Guess what happened; a repeat of the 56 KBPS NSFNET in a more confined environment. If such implementations become at all widespread, and that one did within the company that wrote it, it gets to compete with itself, and it's not a pretty sight. There are other ways to deal with that kind of thing than "we who are wise thumb our collective noses in your general direction". In the end, money talks, and customers prefer networks that work and transport implementations that work in those networks.

I personally don't have a problem with the *ability* to configure something; where I think we have issues is the *necessity*. On your other questions, I might refer you to the sixth recommendation; if we don't have papers that tell us that, let's write some.