From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (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 D8A9B3B2A4 for ; Thu, 11 Aug 2022 16:22:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1660249349; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kKc89xc8DQI9ZfORYVoxQU7p5JI2bPREvNbhkFGZ5jA=; b=INPyjeJXsHeZRreN0uaR3LsXBIzsG9En7OkQx0gRfm3t4SD09dqp+b0sTQsIPSZnZcldek i54s0BEqGa2pmnu0gaM9KAjJQITrbHkaYpBDww1CV1YGxpfxJ72NExDciE3djPez2xPv+k Aoc/J/CRaAbvWSDGN0LQHuTqbxO5+vc= Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2174.outbound.protection.outlook.com [104.47.71.174]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-48-Q2oMetjKPx6Yhqcd2ApSUg-1; Fri, 12 Aug 2022 06:22:28 +1000 X-MC-Unique: Q2oMetjKPx6Yhqcd2ApSUg-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by SYAPR01MB2317.ausprd01.prod.outlook.com (2603:10c6:1:7::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.16; Thu, 11 Aug 2022 20:22:26 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::5599:3984:44a0:fa3d]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::5599:3984:44a0:fa3d%3]) with mapi id 15.20.5504.022; Thu, 11 Aug 2022 20:22:26 +0000 Message-ID: <3c1a8349-3877-644c-93d5-ed0b29c4ef92@auckland.ac.nz> Date: Fri, 12 Aug 2022 08:22:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 To: starlink@lists.bufferbloat.net References: <1660246489.6578887@apps.rackspace.com> From: Ulrich Speidel In-Reply-To: <1660246489.6578887@apps.rackspace.com> X-ClientProxiedBy: SYBPR01CA0113.ausprd01.prod.outlook.com (2603:10c6:10:1::29) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7ece3cb6-3ad2-4a59-b4cd-08da7bd734f8 X-MS-TrafficTypeDiagnostic: SYAPR01MB2317:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: IEG+XH+Jx+AF5D4oNFR3WgBtmJb5sOvLAPhM8hQQEJyZ9VDSdTlwdijHpS1bHxrNhJH16ipn5vKrLUWhcZEuLbIFbwhJ1oY0Nh/vW0FOg3MHreQQ9FSdnC7TsGXm+GoI23PbbiSlBb+Bnl+xvi6R33k5QzswkqcuWh+wS2StlQ/w0Hp3dlGFiCGlX5B5lBPIj4NGRMSvjfSTvyhKLdMLyC+lT62g7HTzWr4ZsXuZqgqjSvS8WBGStAAkNTPpPJ2dLSVh3HhTMs7ZqXvRub3vtnATGWqcWg9eTPFbdxL51WNgJL7dOHsMibAxQdBInISDS4Zes8t8u8zgWquP1di1P61NgYs9S7zKbIJkeS+s+LlO/bDiILOL1MY1rn2XLjN8yTgA1lxsQ80PFiVCVWC+Wp6WRr6Xi3iftkSO4Gn6S7rUifg3W7C2IQxHDVqbY648ikRQTOfLnzziCUdKgRm2Kywew4gFpYNQrlHyY9Yc00nWXCQw3Zt8pXWb0Ca0I51vTwDciLl8nWsdmdRWMkKwxQ1baxuSx80LgqQVLqDseeYED9ZDmQFLJ2fVEVcXr0bYm84yCE5Sh7MSa74Hsbjr07LfsD8gfSdwLR8VbWzbh0XimF2kP85sz4OM3GMqi1dDb/mWMSI7G2DtsT4iMBUvfbIptX4QtKVRw6PZh52tzU+3W9k/Lc2ogW9hUEYFlAAvRKW99LeCCf6INUSSLuGzmrWt9DVEDlDs7/qCLpvmwAlUWPiz8rnCu4tw7fk3s26xmG6akOBjBH1k5jNQTcBl3hluRUjx1MJj8yjXmedDqfsDHsBBZr3CuxJtjVR1SJjFC7IV5b0qwhtpyLhUvRxqGXbs82qPERo8ST0c/Y/gG+UrX7X8tgdRBYKR0somX3OX X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6979.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(376002)(136003)(396003)(39860400002)(346002)(366004)(186003)(6506007)(86362001)(41300700001)(53546011)(31696002)(83380400001)(316002)(8676002)(6512007)(33964004)(2616005)(6916009)(786003)(66556008)(8936002)(478600001)(2906002)(66946007)(36756003)(6486002)(966005)(38100700002)(5660300002)(31686004)(166002)(66476007)(45980500001)(43740500002); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VFBsQjZGMzRiSG9pYlgwdVVXbTFLNk1EODIrZlVsRWhsQjJ0MzU1RW4wc2pF?= =?utf-8?B?OEpZeXNuYUtLUk03dHdYSFRUT2xkdlFsRFVHbmFXdjBhNmt1R0p0WDBwRkhl?= =?utf-8?B?Vjk2UU9VVGhuaG83Qk1ZRVhKNXZHUjFwaWFuUkdmUEorYm9sM284am4wYTdm?= =?utf-8?B?a0JNeEJ5VkJvRWE0Z1YvQzM1dHE4UlYya3BUUEFWdit3cEsrQTQ0K2Vtc2Jt?= =?utf-8?B?Tkw3UlBzRDNLNHpJb3ZXM2t4T2RnWGNId2pVNlMyc3lxaEFLQVFqUnlnZHYy?= =?utf-8?B?NWQ4RXRpMWdnUTh2QmtFR09tR0ljVjJvT0I3Z2ZLbktmeTcrcEtwSmZDQjdE?= =?utf-8?B?bjd5cUc2OFVXaW8vVkZLYW5yalQ4a1gyQjNXT1BTNE94a3ljaUhqcDlUREt2?= =?utf-8?B?Sy95WDBYcXE2eUJiK2tiTjdMeEZPVnFZOWFXSnZsRGd5cUNLa1g3S3lST0Rm?= =?utf-8?B?cTZrVko0b2tKbmJwWGZ3eFZvaG5pTThSQSs0L1IwR2xEQitkbmY5REJ5MWlz?= =?utf-8?B?UjAwc2VJR1gzTDd5TmJ0Q3h3YTZKTmNHaFUrSjJmZFo4empGRHlHOVhVRjhx?= =?utf-8?B?UkpXMnRVWVZGbEUzV21nRkhzWVFKbGdRTmJQb3EwdXR2SG8reGpqeHY1UlFZ?= =?utf-8?B?cVV4ZGcwVk5tMWs1WDE3TGFUTTlIKzJBL2c0YTZMTHhJRVBBTFJWc1FzM2Ri?= =?utf-8?B?Mi83bDRhbUdCWEM4SWUrWUw2STcvZjArRXQyUk81SUxYYWs2cUxmUERPY2hu?= =?utf-8?B?NWoxc0RTQjQ2aWxUalBjZEFidEJlUmdPamVHd2FNVHQydDhoaEZzdDlIck5r?= =?utf-8?B?ckxMWmcyd0JoWGJmQ3dOalFneXpYaUlBdzJUZ1A4WW5KeGhhSklMeWM4N0hm?= =?utf-8?B?Wkl3Z3pETlAxOFN1dU12eE42WlJZTHhtNWc0R3pPSVQxN2RMV3ZEa0VTWWxi?= =?utf-8?B?RnZkbGRESG5wd1AwTC94aklsSFQ0Mk04d2dTL1pYU2t1bU1uM25KV25BV2Rj?= =?utf-8?B?UXkxYmlXcjhnQkFjV0ZlcThaS2JFSDhLbEpkNXJaSkplbTNoeWdmNE1scm9l?= =?utf-8?B?VTBxYXU1MFBaTXhnUHlnZ3Q5NkdJMDV3bFptSUV2RkRDV0NyQy9BWWJDWFVD?= =?utf-8?B?dGZ5YTJ0UnNpS05CamRxMGpZZUJRVHZmYnNRTnZSbHN3RXdsMHFIOWF0QWFU?= =?utf-8?B?aWpVV2c3ZXFsR1JjL1NCMVRzbEhIMWVnaDZHOFNJWmhGTUdtUkRrekpDbExR?= =?utf-8?B?bng0TVNoV1lZSlIycHZtWlhjdHBSWjVEaGk0OG5lelM0azh1SjZZTWtCZlFN?= =?utf-8?B?R3ZJbzVZNlREV1NTc0NUdzUvK1RvbGFiTU5aZEpyRjVDaElNdUREaXNwT1hB?= =?utf-8?B?WHZvek53YXRHUE82WjBDTFIvb2oyTkQ5UDQ5amlLaEQ1c2ZGVUM1RXBHa0ZZ?= =?utf-8?B?WlpnL1ZFL1hlaC9NZG9FWityWlFVUVJKUFhxOGw4UHJ5RFZiVlJERDZFK2tO?= =?utf-8?B?c2VTWWhnOWxyY2puRTdFOU1WZkJuK2haUUoxUXJCOTBPWHpVbEE0VUNoT2ov?= =?utf-8?B?TkVQeXVNQ1YydmhTUG5INVh6VGROVmNIUU1rVGw1OTdGa2V4WkI3cnZCSUtH?= =?utf-8?B?dkloL2hLN2hSZEQxdjM3MGFORjFrSHZkdG1nelZvaWthWTVRODI4NFh6eERj?= =?utf-8?B?VDk4V09QeUkxdmtMV0dyM3BCM1M3bStRVTJ3WHpFcm1vK3NyN283MkNFZWlH?= =?utf-8?B?d21MUVhMQmhFQnZUaUxSeTFWVUpNRXJ4NVd0a2xyYUE3QThDV1hoVkdoN1FF?= =?utf-8?B?c2ZuMmJKT0tRcEVhdkR1L3U3SzlyaklqOU1FbDZZTmhJaWNobkpCcmRqN1Iz?= =?utf-8?B?YlR0aVFnZjV3NjAwSStRWFVPSVl3OU1ZZCtRTTJpQUFLak55WC9McHg2UGhh?= =?utf-8?B?dVNwbVJldDNOekxjOGM1cUVzdzZnWjMzVncvNnVUWlgxdlJlcytoakhXSjhq?= =?utf-8?B?YWx6eklRNDNhWkNKOElidDBMUm5aY1hlODhBSWVvMFRSc3plS3o1Tm9CM293?= =?utf-8?B?S1Q2emE0dnpMUVhtY1BUVSsrVUdRRjNVTS9UVlk3R2Rqc0pRbEVlRUZKeGlP?= =?utf-8?B?RURpSXhjTkpvR1VXT2c1eDc0MjA3Smc2TldHOXAxVk9aeGpiVkwrdGdMQmNY?= =?utf-8?B?YisrS3RNRHkxUHdPWmVpaE1iSE1PbEVHSEYybVcxbGZQb3RNRkZKUUFDYWNs?= =?utf-8?B?cndEVngxNllHcWZHMFFrL2Q2N0h3PT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 7ece3cb6-3ad2-4a59-b4cd-08da7bd734f8 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2022 20:22:26.4495 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Z2+MYC5jjYM1KuRwWUsOWCyQUvGcfdhEGDGJv2myF/9muJfrj2P1xJKlwYw4g8809gBHc+z4MVUilh/5hcnIwHPZpyesPE/H4XcQDrIo/rc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYAPR01MB2317 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------K8ta0iHe4uhT2D7B6xO6AEjW" Content-Language: en-US Subject: Re: [Starlink] SIGCOMM MIT paper: Starvation in e2e congestion control X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2022 20:22:32 -0000 --------------K8ta0iHe4uhT2D7B6xO6AEjW Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 12/08/2022 7:34 am, David P. Reed via Starlink wrote: > > I'll give you another example of a serious misuse of a theorem outside=20 > its range of applicability: > > Shannon proved a channel capacity theorem: C =3D W log(S / N). The proof= =20 > is mathematical, and correct. > Indeed. > > But hiding in the assumptions are some very strong and rarely=20 > applicable conditions. It was a very useful result in founding=20 > information theory. > > But... it is now called "Shannon's Law" and asserted to be true and=20 > applicable to ALL communications systems. > ...and it is. But it needs to be applied correctly. > > This turns out not to be correct. And it is hardly ever correct in=20 > practice. > Ahem ... if it's proven, it's correct, even in practice ;-) > > An example of non-correct application turns out to be when multiple=20 > transmissions of electromagnetic waves occur at the same time. EE=20 > practice is to treat "all other signals" as Gaussian Noise. They are=20 > not - they never are > Therein lies the problem. Correct theorem, incorrectly applied. > > . > > So, later information theorists discovered that where there are=20 > multiple signals received by a single receiving antenna, and only a=20 > little noise (usually from the RF Front End of the receiver, not the=20 > environment) the Slepian-Wolf capacity theorem applies C =3D W=20 > log(\sum(S[i]. i=3D1,N) /W). > Note: N here isn't the noise power (just the number of signals). > > That's a LOT more capacity than Shannon's Law predicts, especially in=20 > narrowband signalling. > Only if you lump in correlated signals with noise, which is an incorrect=20 (or rather, over-simplified) application of the Shannon-Hartley theorem. > > And noise itself is actually "measurement error" at the receiver,=20 > which is rarely Gaussian, in fact it really is quite predictable=20 > and/or removable. > Noise in the Shannon sense is random and therefore not predictable or=20 correlated. Interference can be both predictable and correlated, and=20 therefore can sometimes be removed / to an extent. Modelling=20 interference as noise means not exploiting its inherent properties, and=20 yes that means ending lower capacity. But that doesn't mean that either=20 theorem is inapplicable - Shannon's fundamental limit still holds, even=20 in the multi-user case, as long as the noise you plug in is the "little=20 noise" from the RF front end and leave the interference out. The point I guess is that models are just models, and the more you know=20 about what it is that you are dealing with, the better you can model. Which, I suppose, applies to managing queues also. The more you know=20 what's in them and how it'll respond when you manage it, the better. --=20 **************************************************************** Dr. Ulrich Speidel School of Computer Science Room 303S.594 (City Campus) The University of Auckland u.speidel@auckland.ac.nz =20 http://www.cs.auckland.ac.nz/~ulrich/ **************************************************************** --------------K8ta0iHe4uhT2D7B6xO6AEjW Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 12/08/2022 7:34 am, David P. Reed via Starlink wrote:
=20

I'll give you another example of a serious misuse of a theorem outside its range of applicability:

 

Shannon proved a channel capacity theorem: C =3D W log(S / N). The proof is mathematical, and correct.

Indeed.

But hiding in the assumptions are some very strong and rarely applicable conditions. It was a very useful result in founding information theory.

 

But... it is now called "Shannon's Law" and asserted to be true and applicabl= e to ALL communications systems.

...and it is. But it needs to be applied correctly.

 

This turns out not to be correct. And it is hardly ever correct in practice.

Ahem ... if it's proven, it's correct, even in practice ;-)

An example of non-correct application turns out to be when multiple transmissions of electromagnetic waves occur at the same time. EE practice is to treat "all other signals" as Gaussian Noise. They = are not - they never are

Therein lies the problem. Correct theorem, incorrectly applied.

.

So, later information theorists discovered that where there are multiple signals received by a single receiving antenna, and only a little noise (usually from the RF Front End of the receiver, not the environment) the Slepian-Wolf capacity theorem applies C =3D W log(\sum(S[i]. i=3D1,N) /W).

Note: N here isn't the noise powe= r (just the number of signals).

That's a LOT more capacity than Shannon's Law predicts, especially in narrowband signalling.

Only if you lump in correlated signals with noise, which is an incorrect (or rather, over-simplified) application of the Shannon-Hartley theorem.=

And noise itself is actually "measurement error" at the receiver, which i= s rarely Gaussian, in fact it really is quite predictable and/or removable.

Noise in the Shannon sense is random and therefore not predictable or correlated. Interference can be both predictable and correlated, and therefore can sometimes be removed / to an extent. Modelling interference as noise means not exploiting its inherent properties, and yes that means ending lower capacity. But that doesn't mean that either theorem is inapplicable - Shannon's fundamental limit still holds, even in the multi-user case, as long as the noise you plug in is the "little noise" fro= m the RF front end and leave the interference out.

The point I guess is that models are just models, and the more you know about what it is that you are dealing with, the better you can model.

Which, I suppose, applies to managing queues also. The more you know what's in them and how it'll respond when you manage it, the better.

--=20
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz=20
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
--------------K8ta0iHe4uhT2D7B6xO6AEjW--