From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D41AB3B2A4 for ; Thu, 30 Nov 2017 11:51:41 -0500 (EST) Received: by mail-qt0-x232.google.com with SMTP id d15so9544796qte.4 for ; Thu, 30 Nov 2017 08:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qIPTrHwrbxiIkKQ9KWXgVhMIG0/BQNtq1xxfwcjzyFI=; b=CoYPYHbrkXDXkNbdcCZJwwrrc5SkYTe+DDzPURbPT1IG0cD93AvDD0m/S7t/uH+sVs fDvWr8j41GH9qvTiGTZacZN+wGANvX27vNLwMr9vKit2Bi0jqEmb9yVCDEJE7nR5MXsz gitVJIWBlT5JF4JF2E5JBpe/ENO/s7xFmQ6rucuLWiML0rNi5KRiGQ3Pa3hr5DydbnkK IX53EvyfSmyYcpXMXyD1fses8NvbkIG+TFgS1UE1G7TDrpFnACu47WB1sc6e4mrk+xZx RMXVJG7lkHOrLBi62qUL+CrVOSh1cqZljLczz8c1s9PHZ3u1j8w1d9Abyrjrp8xa+wyo Mh3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qIPTrHwrbxiIkKQ9KWXgVhMIG0/BQNtq1xxfwcjzyFI=; b=TaEp6dGBWfaK3pQy9GxfpACVd+18Ay7IJ6wfJvlGsnNfmN9BQZgU//7Lri9jSi2nxK EOC6ouVuzYI/ph7vsGQP0qb9w5MvHo31tfxcCDINWJtbXmmGgLrl1GQRLIjD0iPZHQhD OsBqPwlRBGSEfCZF9J0wPysno9wOM+owvwkXat4ElvPIubKnzleFsHyEzWj6gvdmzOtk gMtn2BUTVmuO+AVPuu1fprv3igGDue0HIzlV5i4wtDiwHomcH82atpB0q5Vgr/NmTIZy 9+StNYjJsVfVyH/O7Iji5JXB6lGpySHWUYJWbEjikDUxWAtBZJjqyXhXOg9eqohtis+M Y/eg== X-Gm-Message-State: AKGB3mLOSNTNqF3jUANeVDbUAomjHxgHnYJpT0QTgrpnmIPTQbp6jlUJ 8+tuxG0KQLceSXbEVqtBfOC1Et+mU3IxGNyz95g= X-Google-Smtp-Source: AGs4zMaBVtKA5zBWPsSQ3rlGjV2T5eqa/kfVQZNb+azrQbYgHtWMIsBMmN1KFa4T8SCnIgR8S9RAgy+HCSameF9gH7Y= X-Received: by 10.237.59.183 with SMTP id r52mr2271130qte.121.1512060701345; Thu, 30 Nov 2017 08:51:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.102.179 with HTTP; Thu, 30 Nov 2017 08:51:40 -0800 (PST) Received: by 10.140.102.179 with HTTP; Thu, 30 Nov 2017 08:51:40 -0800 (PST) In-Reply-To: <57A2696A-F95C-4EEC-95B7-45EC4C2ADA55@pnsol.com> References: <87shd18c51.fsf@toke.dk> <874lpe8y2f.fsf@toke.dk> <57A2696A-F95C-4EEC-95B7-45EC4C2ADA55@pnsol.com> From: Jonathan Morton Date: Thu, 30 Nov 2017 18:51:40 +0200 Message-ID: To: Neil Davies Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , bloat Content-Type: multipart/alternative; boundary="94eb2c192110fb8b22055f3610a6" Subject: Re: [Bloat] Bufferbloat in high resolution + non-stationarity X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 16:51:41 -0000 --94eb2c192110fb8b22055f3610a6 Content-Type: text/plain; charset="UTF-8" A central assumption in all of your references so far is that the relevant traffic classes can be distinguished reliably in realtime and sent to appropriate queues. There is no fallback mechanism given for any cases where this assumption is false - the queue within each class is a FIFO, which as each paper notes is utterly incapable of providing the required quality, or even an approximation to it, by itself. In practice, we have found traffic classification to be a major problem in terms of deployment. Although some classes are easy to identify by layer-4 protocol and port, some important traffic (from a quality management point of view) deliberately obscures its identity to avoid censorship, while other types are simply difficult to distinguish from best-effort web traffic because they piggy-back on the HTTP port and protocol. The TOS/DSCP field, which could theoretically be useful here, is rarely used in practice by applications, and is frequently mangled by ISPs as part of their own traffic management. I submit that to provide *deployable* QoS schemes, you must either solve the classification problem elegantly (which is a Hard Problem), or else show that your scheme works adequately in the absence of classification. I'm taking the latter approach with Cake, even though it *also* supports Diffserv awareness to enhance its performance where classification is straightforward. My earlier point was that the scenario given in your 2003 paper could be satisfied with *no* a-priori knowledge, classification or configuration, merely a good flow-isolation algorithm operating on the 5-tuple. In 2003, you may not have known about DRR++, but it is widely deployed today as part of fq_codel and meets those criteria by default. In your 2005 paper, I find you in the curious position of assuming that an "ad hoc" network can have a sophisticated QoS scheme, dynamically configured to match the offered load (which for the experiment required manual trial and error), in a way that supports *safety critical* levels of service. You then establish the frankly unsurprising results that strictly prioritising critical traffic over the rest improves its quality of service, and that it is possible to adequately service all traffic if the network is not driven into saturation. I stopped reading at that point; I have little patience for laborious proof of the obvious. Being able to measure a network well *is* potentially useful. The papers and articles you've linked so far do *not* disclose anything useful. - Jonathan Morton --94eb2c192110fb8b22055f3610a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A central assumption in all of your references so far is tha= t the relevant traffic classes can be distinguished reliably in realtime an= d sent to appropriate queues.=C2=A0 There is no fallback mechanism given fo= r any cases where this assumption is false - the queue within each class is= a FIFO, which as each paper notes is utterly incapable of providing the re= quired quality, or even an approximation to it, by itself.

In practice, we have found traffic classification to be a ma= jor problem in terms of deployment.=C2=A0 Although some classes are easy to= identify by layer-4 protocol and port, some important traffic (from a qual= ity management point of view) deliberately obscures its identity to avoid c= ensorship, while other types are simply difficult to distinguish from best-= effort web traffic because they piggy-back on the HTTP port and protocol.= =C2=A0 The TOS/DSCP field, which could theoretically be useful here, is rar= ely used in practice by applications, and is frequently mangled by ISPs as = part of their own traffic management.

I submit that to provide *deployable* QoS schemes, you must = either solve the classification problem elegantly (which is a Hard Problem)= , or else show that your scheme works adequately in the absence of classifi= cation.=C2=A0 I'm taking the latter approach with Cake, even though it = *also* supports Diffserv awareness to enhance its performance where classif= ication is straightforward.

My earlier point was that the scenario given in your 2003 pa= per could be satisfied with *no* a-priori knowledge, classification or conf= iguration, merely a good flow-isolation algorithm operating on the 5-tuple.= =C2=A0 In 2003, you may not have known about DRR++, but it is widely deploy= ed today as part of fq_codel and meets those criteria by default.

In your 2005 paper, I find you in the curious position of as= suming that an "ad hoc" network can have a sophisticated QoS sche= me, dynamically configured to match the offered load (which for the experim= ent required manual trial and error), in a way that supports *safety critic= al* levels of service.=C2=A0 You then establish the frankly unsurprising re= sults that strictly prioritising critical traffic over the rest improves it= s quality of service, and that it is possible to adequately service all tra= ffic if the network is not driven into saturation.=C2=A0 I stopped reading = at that point; I have little patience for laborious proof of the obvious.

Being able to measure a network well *is* potentially useful= .=C2=A0 The papers and articles you've linked so far do *not* disclose = anything useful.

- Jonathan Morton

--94eb2c192110fb8b22055f3610a6--