From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 BB8113CB35 for ; Wed, 13 Jul 2022 02:54:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1657695255; bh=v2lCqgCAesU7gWVk5fc6fk8T38/KzNqzcnIZWX2Z+hE=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=aShHtUVmu5deC0beWiUbYNB7RsrTWA4U2uP8YbClIGaEuPoeOplishKhGBWdHglzc +FdjvoYgVLVbULI1dbX/hLkqrAUO+3rTOHiV6gJrU8V4vUoaY35TO7g3oy1A7Calfy 8YhJ3xvjeukwsT5/Frs6+8QOMHIgDgKd0HNnFoAs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MQ5vW-1nyGjH2y5w-00M09S; Wed, 13 Jul 2022 08:54:15 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 13 Jul 2022 08:54:14 +0200 Cc: bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <6458C1E6-14CB-4A36-8BB3-740525755A95@ifi.uio.no> <7D20BEF3-8A1C-4050-AE6F-66E1B4203EE1@gmx.de> <4E163307-9B8A-4BCF-A2DE-8D7F3C6CCEF4@ifi.uio.no> <95FB54F9-973F-40DE-84BF-90D05A642D6B@ifi.uio.no> <0BAAEF4C-331B-493C-B1F5-47AA648C64F8@ifi.uio.no> <9DF7ADFC-B5FC-4488-AF80-A905FECC17E8@gmx.de> <32A9050A-B81F-4838-BE7F-691F0670DB84@gmx.de> To: David Lang X-Mailer: Apple Mail (2.3696.100.31) X-Provags-ID: V03:K1:/dIwiiGug3lfjYOlxsxZmwuXiXR9fDAX6/Z7VcOMvZPz40ikUAM D2/qY1uk3tf1Db2aIlpJ3tvmh+c1PVxno4tCuooR4507R+reTXH706SaPCVz315A3pP3Lh7 gUr8QLk268fVht9yERTWqly/XKi63lxp/cU0qVVT+b6oHpoi7DHeQHndpOmhrVbQIuzKT0m a+qGVoTKC3HnkR9+cXTvA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:B7sxDvvRepM=:B4L5/yv0Y/ZUkphubuV6/k ZDK6C2b+18NbG4zpe0s2+xwYctTnHuQD/KEEHSXFgpaU1tFxZ3IjPC36PjqjoUdcFvx5Fngw8 Z8+0oiqAKJknrhZ53d2T320M3xrEi1Fxa7O6B43103PQSxfiffPnRZrOdEfl+n570oRBdzxz3 2dNguPaRIu8EslCcjEUIAWUVhQzcueeTkgA3jSuqGGYP0qiNeTpAL7L5qhSEgCmSWNchDatM5 poSQ1I2oV9sr9pCxHI6Ys6Kz4e4UVJ/4O8JfRGUjK524r0LVrbEymRDp7egZ88B1fu2KZ9JbA uHk/M26YA60gpZcYzQEZ6yuxuBaR65O0C72YzADDmdHUHHuy/mIDNhdE8A4f3lGIAwQnHc/7w aHVnuJTz7zCnTMYYpgwPs23YkC9UN3MFgP6E6+O19DCLrY6OVCKYp9AlYNKAhnfsTpEK8V1zR RqqsZuG/oc5qUnSPmq08pj7NpmAR8rKl7MlCqhqTK1GEmDXaoqUFAlDJ4vkSxYU2hQST7OlVw ERdyGZlflpfSW/tZM8p//Wkh8BC3tg3jM7tUtwZx2W1Yw5JVSLC3W+IuoJGyjGgsBG7gMH0Lk AEDx2Fzep2L5UWet6gA5OzPTYZezXJnNlATS4HXecTBXmlSLo0JVorGlD+oku/GC4CebCtBel J+cx7Ohv9z4nKe+rdcVNH/s3bNLM+Mmbt88r/j0tclDvJxjk6fHl8pXx4GyKJYJX97cZG/oQa lK6ZmfOgnTaEs8l2rAP1Bq3cissMvpYkKfPjAvTyeItH7aCfWzt6BmBwRKIZu+ueV9p2Am95j hDqPxYE5dMhvQt6r2PGg4OKajqx9LYy9vePYehW71Vtwwd2QX74ds439IAFDfHuj6qmzXYZ5S 6wY20X160B6+qwbEk75hsfePY2S+ZmG5W3PY8IKzaYho4WZ3ma6iKntuXZNVa7W25C9Z3Y6BM 89j+c0uLkw6DdtzKqGlkQhqjr/9kzfmClKOXmPulxcloJ5uDwlziKNxhZBMTrW0PUE/4jlUYZ kYNvrBFbazvfAQdVO7VDy39iQeml1NO2PS5A7DWJuzuVSSbi6yZsfWL0uxxe4Vqz9a2WRKCX9 zNRTJj7Cf/MtRv9Rtfa4v5vezkz4uUcbfuOLscOcSeHPT/R/adQ9tgQjA== Subject: Re: [Bloat] [iccrg] Musings on the future of Internet Congestion Control 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: Wed, 13 Jul 2022 06:54:19 -0000 Hi David, > On Jul 12, 2022, at 21:22, David Lang wrote: >=20 > On Tue, 12 Jul 2022, Sebastian Moeller wrote: >=20 >> Hi David, >>=20 >> Thanks! >>=20 >>> On Jul 12, 2022, at 19:56, David Lang wrote: >>>=20 >>> On Tue, 12 Jul 2022, Sebastian Moeller via Bloat wrote: >>>=20 >>>>>>> There are plenty of useful things that they can do and yes, I = personally think they=E2=80=99re the way of the future - but **not** in = their current form, where they must =E2=80=9Clie=E2=80=9D to TCP, cause = ossification, >>>>>>=20 >>>>>> [SM] Here I happily agree, if we can get the nagative = side-effects removed that would be great, however is that actually = feasible or just desirable? >>>>>>> etc. PEPs have never been considered as part of the congestion = control design - when they came on the scene, in the IETF, they were = despised for breaking the architecture, and then all the trouble with = how they need to play tricks was discovered (spoofing IP addresses, = making assumptions about header fields, and whatnot). That doesn=E2=80=99t= mean that a very different kind of PEP - one which is authenticated and = speaks an agreed-upon protocol - couldn=E2=80=99t be a good solution. >>>>>>=20 >>>>>> [SM] Again, I agree it could in theory especially if = well-architected. >>>>> That=E2=80=99s what I=E2=80=99m advocating. >>>>=20 >>>> [SM] Well, can you give an example of an existing = well-architected PEP as proof of principle? >>>=20 >>> the windows protocols work very poorly over high latency links (i.e. = long distance links) and the PEPs that short circuit those protocols = make life much nicer for users as well as reducing network traffic. >>=20 >> [SM] Windows protocols, like in microsoft's server message block = (smb) protocol or as in "protocols using data windows", like TCP's = congestion and receive window? >=20 > microsoft windows smb [SM2] Thanks! >=20 >>> it's a nasty protocol to start with, but it's the reality on the = ground and proxies do help a lot. >>=20 >> [SM] Are such proxies located in third party middle = boxes/proxies or are these part of microsoft's software suite for = enterprises (assuming the first as answer to my question)? >=20 > third party middle boxes that you put in each office as a proxy. >=20 > David Lang [SM2] Interesting, I had actually noted that accessing files via my work = VPN is a pain (in both windows and macos, as the servers use SMB). My = work around was to use microsofts remote desktop (which on my access = link feels reasonably snappy) to do most work remotely and also offers = to transfer files, so I did all the heavy processing remotely and only = exchanged either initial input or final output files, essentially = working around the fact that SMB is less than impressive once the RTT = goes into the milliseconds range... (However I wonder, with a filesystem = essentially being a general purpose database designed for arbitrarily = large blobs, how much of that issue is inherent to the problem and how = much avoidable pain did microsoft add when designing their protocol?) Kind Regards Sebastian