From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3469C3B29D for ; Thu, 3 Nov 2022 04:20:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1667463632; x=1698999632; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bs7qfFadIOLLQ3Z2EQpVBeRx6gLxQniA0mf6XzWGTAQ=; b=fDvTtyUTxbZz+CkxXJ7HAG2+OODYJhlv0GtQOyXRyZPh4HHSIor+2h4I jG/5+LQQAckfLnSXUHoMUqFFzgGLtlvbdeA05LJDhwPITT3mo33EeRAED vPBgwnyP7LsMq0vl6mpMlw1J2nVfaVj8w2HfVclzCIm2x/k5N5DEVufOM OF0ESlaeXJn/oQqSzaQiW0zEL+uPJ6GFe/6qLtU+WTIu5bHyYOv/D8LbF WRG9qWRS+CTwRbSt1K5FSMdf9T/tbdOExTnDghmONUYJEC+d7fNt0vF+d kE/Zp3beZDSI81BM/m+z/p/fJ9ots/yIOh3IOpMdj4qvc/5mkJjsaGZQ8 w==; Received: from qdefcs.de.t-internal.com ([10.171.254.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 03 Nov 2022 09:20:30 +0100 IronPort-SDR: smrfBXLikxoQf8/acjG3vMCQckLKL/Q+R0OcNz+akg/6U5D9ItqGvnrj3C7OE8EXjE+/Bk8qL2 zcBeh21uhbwzEMmB5bMa0lLu49LCzqSGg= X-IronPort-AV: E=Sophos;i="5.95,235,1661810400"; d="scan'208";a="616692991" X-MGA-submission: =?us-ascii?q?MDF9kK2ngnzFlxoW4oTkVlKp9RwxBFeExDAbHx?= =?us-ascii?q?377ycZ97Q8pWVgYLQLsjDPrAz5LWeXVwiY7wDmgUV1aJokz3VYpwb88W?= =?us-ascii?q?3B0DB2KoZ4JjwO294i6Y460f4PIm7QMuxLWIs7/ErLYLxPjDfHFRj/Mk?= =?us-ascii?q?cGtRw3riYAA7ETQPsx4z4mxA=3D=3D?= Received: from he105715.emea1.cds.t-internal.com ([10.169.118.51]) by QDEFCV.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 03 Nov 2022 09:20:30 +0100 Received: from HE105717.EMEA1.cds.t-internal.com (10.169.118.53) by HE105715.emea1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 3 Nov 2022 09:20:29 +0100 Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105717.EMEA1.cds.t-internal.com (10.169.118.53) with Microsoft SMTP Server (TLS) id 15.0.1497.42 via Frontend Transport; Thu, 3 Nov 2022 09:20:29 +0100 Received: from DEU01-FR2-obe.outbound.protection.outlook.com (104.47.11.170) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1497.36; Thu, 3 Nov 2022 09:20:29 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fCMXB9tAb5g1HAVQ29RP4SXhkVQCw3wMA617IWuUtYRknPhUfiovhecReqrUClXyKaPIF/As1iPkmHaIMFIPX1RqHiEzVs86Dm069k+FpCV7tZyW5Ks27OhH3MBVd2Z5u2rMFJTdH817dUlh5J0cIq+iZDeis1JR9rp3QK4e9XbM7hyY103jfjNqy7Q+AixtY79LcAMC1NaKsJcQCFlH543Z5WlXSc97BXz49u+Z4fq3/XCBs8Svi28iJYyI9gB/UqGTr7Tp0GYDUBLMHyMWW51H/QnpC6OkAWoTrvkj1ataDo4PW1mg47ZGrX0a59Keb7A4UYFAmT7nmAd3sApLKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bs7qfFadIOLLQ3Z2EQpVBeRx6gLxQniA0mf6XzWGTAQ=; b=MXAgy+UnOlQHBKzjrjNXcyZFSxzkeba54FhjN4U/d97IjVx7c2C3uO3uRj8Gucnlaq7XFXpDtsp1uiA6gIeR/GGr6zBSAv4oHkZsoTvU8hEidhhky7JPuLf8bG0GSNxse8tra1orROtazq/Bj9e9jzUTIDa5xYwb67mIwCHqIdESPnLqg68vKEoc00iIdeOJGk6ibr7aYODX2B3dGIAgVhPF1ZBHD27rDM6Gbs9uVrb//UeJGxLO7nIejW1X5Ayq9252PuPvYxkGJ2uWRUdRplF7A0TdpXPy2dKTsnD/ocnpAcGZj85/Lqp6Q1U7mV5YXUZSUO9MLxX18Y3IISVnqg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:8b::11) by BE1P281MB1506.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:1d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5769.19; Thu, 3 Nov 2022 08:20:28 +0000 Received: from FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM ([fe80::54f3:8989:c087:dabf]) by FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM ([fe80::54f3:8989:c087:dabf%3]) with mapi id 15.20.5791.022; Thu, 3 Nov 2022 08:20:28 +0000 From: To: CC: , , Thread-Topic: [ippm] [Rpm] lightweight active sensing of bandwidth and buffering Thread-Index: AQHY7pSSe1jemA1+oU+yIbz2XUvgw64rWCuggADST4CAAK+jMA== Date: Thu, 3 Nov 2022 08:20:28 +0000 Message-ID: References: <0a8cc31c7077918bf84fddf9db50db02@rjmcmahon.com> <344f2a33b6bcae4ad4390dcb96f92589@rjmcmahon.com> <261B90F5-FD4E-46D5-BEFE-6BF12D249A28@gmx.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=telekom.de; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: FR2P281MB1527:EE_|BE1P281MB1506:EE_ x-ms-office365-filtering-correlation-id: 4af59368-5dac-41e8-2466-08dabd744477 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gpbAlH+cOrILe6pFC7Y45Vw4D1KSPvYi6tQd+l9kJLbU1jwd4NUm51VE9lPo8T+BVpOsoqyPNrBguYsRA4zC5RXotK+xZtgue4ekxYZAO325IA5RbEBhcEVrkdpTy/2HANFqe5iucRMHkeyjDVvAmObH/C4tr8VvzK7l+UmGtmyiEFR4uPebZYQa+nirkl7sWz9oI9eCb7YXpyJTj/fyIrh1nb7OKMqmRXL/BF8nohQomdTq3tmrvfjGeXmXVIpJMnQhwT1LSzq8hFtbjqOaeNJrt3GsdcNnr3P6Cs3YmG6fEk5GF/OQXLfFOjZ1EQXoozWOvR3+8byw3FWFSXK0XScFFMDbqqG10d8EnInFq04o9pvvv4m9k6EYq0hghAGG9UDVOarFkriOug/5ytRPyUuIVWVNAvBOU2TBcceVHGBN2qYIG8XcBKLQ9dZZYRcETFFMkYGM2bP0vyUBLwXV7uj+CbnvOh5oIvZTztoVAjA2agtw9b4GniQaOPxKg7QPKmJNI7fQ4vsLl8tYFDArH6fCapUhcBZcFf0/m0HmdDuRjC2gr9noNs8r3D5+YOVZx2LDFjnlpmefV+y6w70a4GXSlCO8dB1DurmIK5kHxfcvIyGQseHRtRBpEqJbuixYBBgal5unUGmxQi4xaaYqAsaEYqzF2QKDEvYUh3Iezqe/6bIQTJsj6EP/W1OwDKxSsh2y0pJzu737cqoFiYnKVckLnRmvrN/mdyGtcocMMmZh/sPmtexMCkWXdI8QxqtYstEhja+iMWU6nuqnbJnsAKO7nPmn8O/tlOcRlYcLRWW7wsDDRhPOh8FgKhRjnK9e x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230022)(4636009)(39860400002)(136003)(396003)(346002)(376002)(366004)(451199015)(316002)(54906003)(41300700001)(8936002)(6916009)(52536014)(66446008)(8676002)(5660300002)(66476007)(66946007)(4326008)(76116006)(6506007)(2906002)(966005)(478600001)(186003)(38070700005)(71200400001)(26005)(7696005)(66556008)(53546011)(9686003)(33656002)(66574015)(64756008)(122000001)(86362001)(82960400001)(38100700002)(55016003)(83380400001)(87944006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ItcYsJmLR9dKECBvzXO6yx0sjWHU9uPZyjMCbMD1dndbl+j83HgjKamDV2?= =?iso-8859-1?Q?l9KYTwBXLezp5L/rTBkbJrUmCc9XuFneUEcj4kqMUkxOi3vNz/craGiEeg?= =?iso-8859-1?Q?LoVZdxFL4qDkObQrqEZI7nmvvf+f7YMNrcCM/AdOw22SURzwxdG3vI6b5w?= =?iso-8859-1?Q?lG7wZda4N4x5p86pVAIcrCzLY7+mPGE0070DBFYBkLuXP2q76v7K5LMREj?= =?iso-8859-1?Q?7zqgFn8NyQV2v4G5L9CJ8/uk0Vvoc2OrZSfvQC077T/OUZlKufuBA06aE9?= =?iso-8859-1?Q?SoAskuNzsUSBI9Pg8sQgqOIX5d3Isqza/PPWiI7L//fL1rErhjHTaaGOPg?= =?iso-8859-1?Q?a5NZAFAUE39hwni4jUgc0uzoWvtKIkIwiv/oEjUruYYuELVxfvYIkv0n+2?= =?iso-8859-1?Q?NBE1zpr//HZdfu7f8V777dTzJcvyu1RM0zLh03Z9Pt8Pnn5VXpuwPVanSI?= =?iso-8859-1?Q?S7ntvmG28J0QX4qr1KP3b1VSxQF33msL+ZVwk1UDC2nYu6JDid5oKpGiJD?= =?iso-8859-1?Q?y/czM63lUf9snJCD8m+bHlxMSHlsqtCibc+qtmOVVKcFRDe0mjzvZXTp+B?= =?iso-8859-1?Q?Yo/Nyw9i1ttKqa/5ttP0AFQxGQAIXyW5egtlid6UjoM8sZvpCx4ip5SBVw?= =?iso-8859-1?Q?zfzUy0xw1mazoESlRifI+Lkte2SczFCxbl5Y2vmknEO12+7ML6WtvT82hm?= =?iso-8859-1?Q?W0P1GUqn5+S+Q9/yeVGbrr10Qaais2cVHOF0sUcnGN59q3glQ+a7SCfeIv?= =?iso-8859-1?Q?sEn2RSdEGo5X6CQ206LLEeHmh//aBeJD29aikopdAiTCi41YzTd3JYyWhP?= =?iso-8859-1?Q?Ty8fkvTpJVixMmmqQ36FaNzWzFytnokSUJUqy2+FFcpj/ymJAgwOc2XgmV?= =?iso-8859-1?Q?wzCZY6w5PzvJ0CBst95qg8vBj8bis5VSRJUHR6DXK+dTK04MPi9SAVvQf2?= =?iso-8859-1?Q?sjdd5dJkMFiaMdMEASSyN8IW19BVlOVSq44QAqQ4ztqOuQC2AAr9MNinO0?= =?iso-8859-1?Q?HItUY4OSsJ8MsjKEAGP/cilgFMfSC1K6YapCt6xQGDmgxI/K4Ca55lxGbG?= =?iso-8859-1?Q?lkvhtAfpgWHyoe+rEcMvf4aqWEaeNqOwAxaKPjNdWQIReR8EeWGW7cwJIw?= =?iso-8859-1?Q?04IK5PzKBzhMSIfLtEAsz2DEeIH6F6utc22hGSb7Dl78d9m9LzrqSJFvnx?= =?iso-8859-1?Q?sOwn0ws1NnOqHnBm5sBFtPLqtmhzKJCcRJuFcUtg9pS3RUccilyxp2rzLG?= =?iso-8859-1?Q?OLPPxKX7YaJsu+DfCfCWhL4fNLb1NWJFLmqXl/dfWZ1VUMyiXRd2y9HmbC?= =?iso-8859-1?Q?tq5NCGgG+WzBeeie+U3BHnJ3pKhn+AY4GpINkt0onMY+f/q2o3J4pLKTMA?= =?iso-8859-1?Q?pTq4y3oPxPvb23wI8/bhJ6yNp5pk+oCnwaIxHuijMnjHGGL4GwNijioGUo?= =?iso-8859-1?Q?5LypheBUDVl2KoG4a+Y63MGQCi2FXQSdRErSnHDk5szV5lHvZBAdDTVF3A?= =?iso-8859-1?Q?NuAxMiWZsZvlh8DX41FqWg+IihVfMhM40voc/sDJZEEdgr92C+6rgAiVJG?= =?iso-8859-1?Q?lRlPVJPUdK/SqDNsm+JF5ZMYUVQucKaMOK6SQuWFL4e9fe/0HwHSWntCJo?= =?iso-8859-1?Q?06zIm9nGU8r7ATaHBkuRJAL7BCTHuGd7OQ?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 4af59368-5dac-41e8-2466-08dabd744477 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2022 08:20:28.8705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JB260Pd2tM5okaVir7Bqt7kTYQmL4Shx9iJ5cIEU+DLVDG0qEHS/I99aylS3vB5T9bNJnKQvg0AoELEVfce38+4xzMRLWZF0XtmfJwX+Z+Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BE1P281MB1506 X-OriginatorOrg: telekom.de Subject: Re: [Rpm] [ippm] lightweight active sensing of bandwidth and buffering X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2022 08:20:32 -0000 Hi Sebastian, [SM] Pragmatically we work with delay increase over baseline, which seems t= o work well enough to be useful, while it is unlikely to be perfect. RG: I agree. And I appreciate "well enough" - many factors may impact delay= s along a measurement path, causing e.g. temporal noise or permanent change= . Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: Sebastian Moeller =20 Gesendet: Mittwoch, 2. November 2022 22:41 An: Geib, R=FCdiger Cc: rjmcmahon ; Rpm ; i= ppm@ietf.org Betreff: Re: [ippm] [Rpm] lightweight active sensing of bandwidth and buffe= ring Dear Ruediger, thank you very much for your helpful information. I will chew over this and= see how/if I can exploit these "development of congestion observations" so= mehow.=20 The goal of these plots is not primarily to detect congestion* (that would = be the core of autorate's functionality, detect increases in delay and resp= ond in reducing the shaper rate to counter act them), but more to show how = well this works (the current rationale is that compared to a situation with= out traffic shaping the difference in high versus low-load CDFs should be n= oticeably** smaller). *) autorate will be in control of an artificial bottleneck and we do measur= e the achieved throughput per direction, so we can reason about "congestion= " based on throughput and delay; the loading is organic in that we simply m= easure the traffic volume per time of what travels over the relevant interf= aces, the delay measurements however are active, which has its pros and con= s... **) Maybe even run a few statistical tests, like Mann-Withney-U/Wilcoxon ra= nksum test and then claim "significantly smaller". I feel a parametric t-te= st might not be in order here, with delay PDFs decidedly non-normal in shap= e (then again they likely are mono-modal, so t-test would still work okayis= h in spite of its core assumption being violated). > On Nov 2, 2022, at 10:41, wrote: >=20 > Bob, Sebastian, >=20 > not being active on your topic, just to add what I observed on congestion= : [SM] I will try to explain how/if we could exploit your observations for o= ur controller > - starts with an increase of jitter, but measured minimum delays still re= main constant. Technically, a queue builds up some of the time, but it isn'= t present permanently. [SM] So in that phase we would expect CDFs to have different slopes, highe= r variance should result in shallower slope? As for using this insight for = the actual controller, I am not sure how that would work; maybe maintaining= a "jitter" base line per reflector and test whether each new sample deviat= es significantly from that base line? That is similar to the approach we ar= e currently taking with delay/RTT. > - buffer fill reaches a "steady state", called bufferbloat on access I=20 > think [SM] I would call it buffer bloat if that steady-state results in too high= delays increases (which to a degree is a subjective judgement). Although i= n accordance with the Nichols/Jacobsen analogy of buffers/queues as shock a= bsorbers a queue with with acceptable steady-state induced delay might not = work too well to even out occasional bursts? > ; technically, OWD increases also for the minimum delays, jitter now decr= eases (what you've described that as "the delay magnitude" decreases or "mi= nimum CDF shift" respectively, if I'm correct). [SM] That is somewhat unfortunate as it is harder to detect quickly than s= omething that simply increases and stays high (like RTT). > I'd expect packet loss to occur, once the buffer fill is on steady state,= but loss might be randomly distributed and could be of a low percentage. [SM] Loss is mostly invisible to our controller (it would need to affect o= ur relatively thin active delay measurement traffic we have no insight into= the rest of the traffic), but more than that the controller's goal is to a= void this situation so hopefully it will be rare and transient. > - a sudden rather long load burst may cause a jump-start to "steady-stat= e" buffer fill. [SM] As would a rather steep drop in available capacity with traffic in-fl= ight sized to the previous larger capacity. This is e.g. what can be observ= ed over shared media like docsis/cable and GSM successors. > The above holds for a slow but steady load increase (where the measuremen= t frequency determines the timescale qualifying "slow"). > - in the end, max-min delay or delay distribution/jitter likely isn't an = easy to handle single metric to identify congestion. [SM] Pragmatically we work with delay increase over baseline, which seems = to work well enough to be useful, while it is unlikely to be perfect. The C= DFs I plotted are really just for making sense post hoc out of the logged d= ata... (cake-autorate is currently designed to maintain a "flight-recorder"= log buffer that can be extracted after noticeable events, and I am trying = to come up with how to slice and dice the data to help explain "noticeable = events" from the limited log data we have). Many Thanks & Kind Regards Sebastian >=20 > Regards, >=20 > Ruediger >=20 >=20 >> On Nov 2, 2022, at 00:39, rjmcmahon via Rpm = wrote: >>=20 >> Bufferbloat shifts the minimum of the latency or OWD CDF. >=20 > [SM] Thank you for spelling this out explicitly, I only worked on a vage= implicit assumption along those lines. However what I want to avoid is usi= ng delay magnitude itself as classifier between high and low load condition= as that seems statistically uncouth to then show that the delay differs be= tween the two classes;).=20 > Yet, your comment convinced me that my current load threshold (at least = for the high load condition) probably is too small, exactly because the "ba= se" of the high-load CDFs coincides with the base of the low-load CDFs impl= ying that the high-load class contains too many samples with decent delay (= which after all is one of the goals of the whole autorate endeavor). >=20 >=20 >> A suggestion is to disable x-axis auto-scaling and start from zero. >=20 > [SM] Will reconsider. I started with start at zero, end then switched=20 > to an x-range that starts with the delay corresponding to 0.01% for=20 > the reflector/condition with the lowest such value and stops at 97.5%=20 > for the reflector/condition with the highest delay value. My rationale=20 > is that the base delay/path delay of each reflector is not all that=20 > informative* (and it can still be learned from reading the x-axis),=20 > the long tail > 50% however is where I expect most differences so I=20 > want to emphasize this and finally I wanted to avoid that the actual=20 > "curvy" part gets compressed so much that all lines more or less=20 > coincide. As I said, I will reconsider this >=20 >=20 > *) We also maintain individual baselines per reflector, so I could just p= lot the differences from baseline, but that would essentially equalize all = reflectors, and I think having a plot that easily shows reflectors with out= lying base delay can be informative when selecting reflector candidates. Ho= wever once we actually switch to OWDs baseline correction might be required= anyways, as due to colck differences ICMP type 13/14 data can have massive= offsets that are mostly indicative of un synched clocks**. >=20 > **) This is whyI would prefer to use NTP servers as reflectors with NTP r= equests, my expectation is all of these should be reasonably synced by defa= ult so that offsets should be in the sane range.... >=20 >=20 >>=20 >> Bob >>> For about 2 years now the cake w-adaptive bandwidth project has been=20 >>> exploring techniques to lightweightedly sense bandwidth and=20 >>> buffering problems. One of my favorites was their discovery that=20 >>> ICMP type 13 got them working OWD from millions of ipv4 devices! >>> They've also explored leveraging ntp and multiple other methods, and=20 >>> have scripts available that do a good job of compensating for 5g and=20 >>> starlink's misbehaviors. >>> They've also pioneered a whole bunch of new graphing techniques,=20 >>> which I do wish were used more than single number summaries=20 >>> especially in analyzing the behaviors of new metrics like rpm,=20 >>> samknows, ookla, and >>> RFC9097 - to see what is being missed. >>> There are thousands of posts about this research topic, a new post=20 >>> on OWD just went by here. >>> https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/135379/793 >>> and of course, I love flent's enormous graphing toolset for=20 >>> simulating and analyzing complex network behaviors. >> _______________________________________________ >> Rpm mailing list >> Rpm@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/rpm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm