From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from CAN01-YQB-obe.outbound.protection.outlook.com (mail-yqbcan01on2132.outbound.protection.outlook.com [40.107.116.132]) (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 51D993B29E for ; Mon, 13 Mar 2023 15:48:15 -0400 (EDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YLN+FqBwqk5V2FPlBFQTSjdHl3Mf/BeLu9PrycOBcCc4guX66TBPtImozk3w8tv6WHq7DyiavaKWx9P4WWm2E3jKY/U36NyK8vB+iXCzD5h8sNFNX3uL5Vllt66JNYeXxDRb1eX/QeAQAeYTPBb4lIHdW8dbk0zj2EL2aeZZOFGnt3wy9AYveUItUSCV9LxB9VUsiqujM4QpVmUHrrzkSRKjXnIT4KnHjC0O67C8DY40/4UDYmjNS5VEpuil9tSuaxSWzFIG6lfZNB30Y70VgEYZmXD+fplW+v9CDe9XCM1ZUcAp1e/4lpNP9qbSf3ekczLPnuno3H2dytXM25Iw+A== 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=ROUTxOp+OMddKySZvbC1q4Dhp+WBF9g5X34jhXrgehQ=; b=CJX1SqA3fiSDFMOIzPA5jSjmyWnnirpFtPpXp6cEWE2hg4sj+nfMIdkT3wzFhE0E9WqiQ4NQHJzwdr32u/2KcJH5dhkcGxh50zj/uz+qXkk7pIr1//k6hNbiloNWKBKsMhKyIgOZolRV4gNcKsB3jHOLlu6gBsd1aTfKe2TOzjL9Eudxuisdee6cCBIXja7WEQljCP9MIfur75/qxvYEWSjR1PEtATPSTk/AK78lEVs4GuX6K6F2rjlIrjCzLDB96y45Qlax6Zvr7UDT0cAMnNBe3OE4VLYadtXTOINSAUQUequ15Pmpd+Xi4elHbQhfGJGBxyhHiSomJ5vqu7UibQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=indexexchange.com; dmarc=pass action=none header.from=indexexchange.com; dkim=pass header.d=indexexchange.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=indexexchange.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ROUTxOp+OMddKySZvbC1q4Dhp+WBF9g5X34jhXrgehQ=; b=vca9dBGjFAMY1PliC2Z6G+AKFBUp3Wv/xxswgdr64zbX/YMN/b6AxCbYptQ+7UvvzJsIX4vxqrI0ZWpTsErW6lZ6KsoOefLgNj2RhSp3PYcELTO2XWSxyP1czhGqLM/KD8r2Xeamgcf+a7ds9Y+/fM2s35HRHsYYEsuKJ4kCwcg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=indexexchange.com; Received: from YQXPR01MB4756.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:1e::12) by YQBPR0101MB5655.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:38::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.24; Mon, 13 Mar 2023 19:48:13 +0000 Received: from YQXPR01MB4756.CANPRD01.PROD.OUTLOOK.COM ([fe80::f079:c1c3:a64c:c327]) by YQXPR01MB4756.CANPRD01.PROD.OUTLOOK.COM ([fe80::f079:c1c3:a64c:c327%5]) with mapi id 15.20.6178.026; Mon, 13 Mar 2023 19:48:13 +0000 Content-Type: multipart/alternative; boundary="------------Rgrm6atuzZ0lAQmcfadd9hq6" Message-ID: <6d5391a8-247d-0c7c-11f1-b3f46cd7db76@indexexchange.com> Date: Mon, 13 Mar 2023 15:48:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Content-Language: en-US To: Sebastian Moeller Cc: bloat@lists.bufferbloat.net References: <1672786712.106922180@apps.rackspace.com> <77CCAD19-07E0-4F9E-88C1-D207CF7BF376@cable.comcast.com> <83ffc0dad19e3343e49271889369cefc@rjmcmahon.com> <45AA2C67-CC59-4222-991C-F43D08699F90@gmx.de> From: Dave Collier-Brown In-Reply-To: X-ClientProxiedBy: YT4PR01CA0284.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:109::12) To YQXPR01MB4756.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:1e::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: YQXPR01MB4756:EE_|YQBPR0101MB5655:EE_ X-MS-Office365-Filtering-Correlation-Id: a0c540f4-8bf4-4e2c-099c-08db23fbe176 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BcUmxYB3E/3QDWu+Hs5pk+Q8TlOX2+E4dBPMtKy35i/5R8Kjk/yxBnADhmiMWXzVWBD3hBlvS4lrBv2slrnp6add9ZOT+mSfjFZ8vxHQJsAZeZlKbpA1Hnke6e3sf9h0Ig81xuAJQ8zYreeeZkbWRrrCxTcwSq+WxRvDnOyWBQd/t0fShkOkmQYDRP4yU/iH4tWYTd7rkFSkkVTR6asNI5gVIUHLWnV6ZxlFPVrvIysWyHQXzWcTgTWO6EEGUAHoOE0uy52tbDzPDI7ryjsUYAArtuikFsc7qSewvNAQBE+sIpl0lKgv/6i8w2Xz0RmLjdj0EolcVADCHd5ywu+H2iaq59s4vmgswGguzCseYDbr3tPCrJgPc76UXUqznhATwz80x6PlCC2/pjFBqjoUZzTvoUdW4iIQ2RdZQuUlZQYt7cfWVK5PRzz5MJivwLkOM9inyKtWB4XklFsBbthXfpF4xadmq3oyfOcJsT1MQH/eXKjVrTsRDSxsb2K90tVKT+FYxbFjSvGhrFBXH7yVekXVra1B6FaA3PE5gQBrdXi+x6zGme0assQeZjewMwHiAdXUTa3QocHDu9sghXMu4T0YVOjbFaDpTHST1w+vy728Vo5ZPQfTKCLqQAu1b81SI5WxFKb6cBfdbNCfUBZY14WsoDUSALmzMafKXZQoxemjT6U/l9uuVuI/j0L6C8UxZDk0ZGKtRctWw4naGpYF3rzZOT1LUPWQz3/Lm6EmJ4I= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR01MB4756.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230025)(4636009)(346002)(396003)(376002)(136003)(39850400004)(366004)(451199018)(2616005)(31686004)(186003)(26005)(6506007)(33964004)(6512007)(53546011)(66899018)(83380400001)(8936002)(30864003)(45080400002)(6486002)(38100700002)(5660300002)(66574015)(966005)(8676002)(66556008)(66476007)(4326008)(2906002)(166002)(41300700001)(6916009)(66946007)(316002)(478600001)(36756003)(31696002)(86362001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dm5RcFRJOFluR1VEQ3JlZmVKTmc5ZnplblVaclJzd01BZlpEMnpkNlFlUXB3?= =?utf-8?B?aUxJVDBHM283Y3FoTEcvMktvdUJBMGI5MWlod3VmYWhBMEVYcit6c09qaDI5?= =?utf-8?B?WkEza0h5b2ptY1VqcXVvemFhaExIQVlPNlp5cU1JRkZwc1J1eXFHOFJlTURw?= =?utf-8?B?b1NuTERnUXhNenN4TTdPVmxSSzkrQUZ3NVQrYlB1ZFYwek84eHl4NForOGY4?= =?utf-8?B?YUJ1WFlDSjVzZEVsMFRvbVhwT0Q5dWEvWlEwM2tad3dVb2c4Q1c5b1RwZDFy?= =?utf-8?B?Vy94emZWT2xYd21oY1E0QWY1akFLNHV0aXl3SFdoLzllSE84UmU1Y2o2aXlH?= =?utf-8?B?dzV1QUpZM1VDdHZDOUZsWDNkU0ZoWGdxd0UzUi80REtEZzJsYmJFQnhGelpt?= =?utf-8?B?MWdCZVlJcWNOd3I1dEQ4eDFpRUh6U1o4ZC9FKzlRTVZvSUkyb0JZZ29MU3JR?= =?utf-8?B?ekR2UTVsWk9DdnNEVU5CY21tT1pGYXRmSTJmbEZJTk9xRFFqMzc2M3BHaGhL?= =?utf-8?B?b1ZFRTZiKzlERTRmTzVmQ3FTRlc3bG9WeVp0UHM4T0ZELzNTYWo3bzZGME9W?= =?utf-8?B?bVIwNlNDVHZ1WGd2Yk4xYjR3VmF5SUxIeHJNQjFDcG13RncyNU11dkpQY1I4?= =?utf-8?B?d1NDWTFhN2hVcmtOM3pENmVBY0g2ditqVlUvSWZpOU1kWmtvZjhlK3FWVVAw?= =?utf-8?B?UnNrZUhncHlyeC80Nll4SEk2SWdsWHArd3owTlhaSEJoOExDdzdhaXhDK0V2?= =?utf-8?B?V3ZRbUluZ1o3R2JaNCtDRVY0dFQvM0QxcDFJSWg2VjNxb1NYWmFOYUlLaHJk?= =?utf-8?B?TVN3OGJTcitqMmJSWWdXN2pwNk9hOGxncEJqZkRpL3lXVHB5ZGVHaWJySzdp?= =?utf-8?B?QmJ0c00rOVhYTHh3SjdOVlZUQTE0VFY2c3JacytaanRWTE8wU0tnWGQ4MlRV?= =?utf-8?B?Nkp1cXhsRDVGYWJsM3RRdHZaYmtwUi9nd2ZxbitTRXlnckMxVWx6VGd2U1dX?= =?utf-8?B?YWVHcDRSVXBoRG1BUk5ENlJZaStQcTBlS3hpQlNDdU1EbzdZUmxnR0lMT1hl?= =?utf-8?B?VU96MERaRkVRUjQ5eVBZeGhFMk9UMFRRSUtuOUkzdUYwNEU1UVhuWllmMTBU?= =?utf-8?B?bEVCQXZkRlZyeVZwVHlRdG00cTNPYlhGa3NGc3BIUmNzSi9tcmdhNDhteUk4?= =?utf-8?B?dWEvQlk2N1dhRHFZaFRkV0xnbXJCS094eXlQaTFUQUxpcVM0Y0FtUUtSSDAy?= =?utf-8?B?NmNXcSt5Umt6Vnl5TE0wT3piNzFrVzlPNkdpTkk1WGREZGFtUEIrbzZ0bHZP?= =?utf-8?B?Rk9pWFQzV0wvZHdPQS9UOXdBalQ5b2o3NytyRmN5bUY4WHBobkgwdWR1WVFM?= =?utf-8?B?RTI2T3p6eDQ2aS9VQVVVb1BZM2c2NmdDL0dFMXFXTStRR1N2S2l1aVllbk9I?= =?utf-8?B?bHlOd1VadGx0aWtGdlc3RUNmK281US9XVlNXOEV0QUdkSGV3cXRzV0IyUUVX?= =?utf-8?B?WkdZcFBVTVNYWVF5ODNHd1dNN1dOMzZ1YzFuTGs0N3JuWlE2cStWV3RweG03?= =?utf-8?B?QmwvZVhXWUZWTElUTXR1MGd4MUo5WDBYbGhvSnBiWWsxa2h2UHBocWdXMVB5?= =?utf-8?B?RnlqRkZ6QmtQY1lHSXlhNy9aekNrWlJXc3VTbFhTWEZ2ZXBNa3pNTHRYQ0dR?= =?utf-8?B?US9tVUZ5TW04NkxkcWZzYjljd1RVUW5SM0RxMkwrWWFsT0dFanluTDZEVmov?= =?utf-8?B?ZDZKQ2JSV2x4RmtLRFBOQVE1T0E5b3JMZjdqVURobW9sWXZJWHExRzd6eFdn?= =?utf-8?B?UHV4WCtBRjBHTzhRc09FWHpadjh0dkhIcmlLekNvVStmczB3aTVQa0pmZjFL?= =?utf-8?B?Z1gwQzArREpZd2YrOVJwb0FiWDdTdmF4RWxvVVViSWZzSzFXSGM1K1dUR05s?= =?utf-8?B?V0tzYWY2dWRhY25ZTGVadGxRbmFpUXVTaGhxSVZPalQ0SU1iUm5hbjNzK1NF?= =?utf-8?B?K0pJZGdVME00akFsUHdNQ1RySWNNRENNbExpUXpBYjVYc2puV1NSYURPWS85?= =?utf-8?B?U0F4ajk0TXRydE5IdkFnai81Wkw4SHFybHNrYXV1S0VEU3g2THBNUkVMcVoy?= =?utf-8?B?bGduLy9QNXBHb1NCZEt3M1pGUE5KK1VZOXpIN0duYm96ZGdTL3pFY3VJUGls?= =?utf-8?Q?7qj2RyJrpMckI4Z/2odUNOQVvr824ngTI9OXVP8luymD?= X-OriginatorOrg: indexexchange.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0c540f4-8bf4-4e2c-099c-08db23fbe176 X-MS-Exchange-CrossTenant-AuthSource: YQXPR01MB4756.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2023 19:48:13.0211 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b07c0690-22b8-4366-8d8d-7b845d088e18 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: X9t/6LUhxAzXXuunnlosSePo3E9CECVteg1cqtM7vWTTPkppntZzdHRhGY1+fnmOohcdWzScDY3DvUeto9iG0LnhdH4HTlz+aUMlPjYOtQEcN4f8PvDWY6RdiIsUeOez X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB5655 Subject: Re: [Bloat] Offtopic: passive ping. was: Researchers Seeking Probe Volunteers in USA 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: Mon, 13 Mar 2023 19:48:15 -0000 --------------Rgrm6atuzZ0lAQmcfadd9hq6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/13/23 14:50, Sebastian Moeller wrote: > [EXTERNAL] This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > Hi Dave, > >> On Mar 13, 2023, at 19:22, Dave Collier-Brown via Bloat wrote: >> >> On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink wrote: >> >>> [SM] OK, I will bite, how do you measure achievable throughput without actually generating it? Packet-pair techniques are notoriously imprecise and have funny failure modes. >> >> When you mention packet-pair techniques, are you referring to Kathleen Nichols' passive ping work, or some other correlation scheme? > [SM] I am referring to what I thought was the classical packet pair method, send two (or more) packets back to back and measure their temporal distance at the receiver then deduce the actual capacity from looking at spacing change as a function of the known packet size... Aha!  I was unaware of that /entirely/. I guess I could say I'm not classically trained (:-)) > so if I sent 2 packets of 100 units through a path of 100000 units/time with a small bottleneck of 10 units/time in the middle, the packets leave back to back, now they queue behind the bottleneck and the first starts to squeeze through taking 10 time units before it can be transmitted further, same for the second packet, now they are spaces with a distance of 10 time units when they hit the receiver and the receiver can estimate the bottleneck capacity. > Now I am sure this is the packet-pair for dummies variant and real methods are a bit more refined, but that is the gist. And it is known not to work robustly and reliably over the internet (some link technologies actually batch up packets or some links send packets in parallel*). One can probably make up for that by a healthy amount of averaging, but doing so makes these capacity estimates less and less immediate. > > Side-note: paced chirping, as far as I understand is a clever extension of this idea, that suffers from the same problem, that packet pair measurements work great in the lab. less so over the internet. > > Side-side-note: you can extend the same idea also and use packets of different length to measure capacity. I did that accidentally as part of my old ATM over head detector approach, where the linear fit of RTT as function of ICMP packet size correlated really well with the inverse sum of uplink and downlink capacity IIRC. Which was neat, but useless and it required linear fitting, if only due to ATM/AAL5's peculiar quantization issues, but I digress. > > >> I'm interested in the idea of measuring packet timings to our customers as a way of detecting short-lived issues, which I find excessively annoying to detect and quantify (;-)) > [SM] Ag, that might actually work, because you are not aiming for "over the whole internet" but over a well known segment mostly under your control, no? I assume you address this with an ISP hat on, not with a content provider hat on? ISP-like service provider, definitely. We're a kind of payment processor for folks who pay for their web sites by having us auction off ad space.  I'm actually in ML/Ops, but have an interest in anything that can mess with our performance (;-)) > > Regards > Sebastian > > *) e,g. measly DSL links essentially use ODFM and send quite a bunch of bits in parallel, so even if a DSL link is the capacity bottleneck, our back to back pair might traverse that link in one fell swoop fooling us about the available capacity. > > >> --dave >> >> -- >> David Collier-Brown, | Always do right. This will gratify >> System Programmer and Author | some people and astonish the rest >> >> dave.collier-brown@indexexchange.com | -- Mark Twain >> >> CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory. >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.bufferbloat.net%2Flistinfo%2Fbloat&data=05%7C01%7C%7C59245dd9ce2f42dae74508db23f3c839%7Cb07c069022b843668d8d7b845d088e18%7C1%7C0%7C638143302165333406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m7iX24gQCPmu%2FLd4%2B5ogy2GGTsnK6FzQw4EwH59ooDA%3D&reserved=0 -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dave.collier-brown@indexexchange.com | -- Mark Twain --------------Rgrm6atuzZ0lAQmcfadd9hq6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 3/13/23 14:50, Sebastian Moeller wrote:
[EXTERNAL] This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Dave,


On Mar 13, 2023, at 19:22, Dave Collier-Brown via Bloat <bloat@lists.bufferbloat.net> wrote:

On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:


   [SM] OK, I will bite, how do you measure achievable throughput without actually generating it? Packet-pair techniques are notoriously imprecise and have funny failure modes.


When you mention packet-pair techniques, are you referring to Kathleen Nichols' passive ping work, or some other correlation scheme?

        [SM] I am referring to what I thought was the classical packet pair method, send two (or more) packets back to back and measure their temporal distance at the receiver then deduce the actual capacity from looking at spacing change as a function of the known packet size...

Aha!  I was unaware of that entirely. I guess I could say I'm not classically trained (:-))

 so if I sent 2 packets of 100 units through a path of 100000 units/time with a small bottleneck of 10 units/time in the middle, the packets leave back to back, now they queue behind the bottleneck and the first starts to squeeze through taking 10 time units before it can be transmitted further, same for the second packet, now they are spaces with a distance of 10 time units when they hit the receiver and the receiver can estimate the bottleneck capacity.
Now I am sure this is the packet-pair for dummies variant and real methods are a bit more refined, but that is the gist. And it is known not to work robustly and reliably over the internet (some link technologies actually batch up packets or some links send packets in parallel*). One can probably make up for that by a healthy amount of averaging, but doing so makes these capacity estimates less and less immediate.

Side-note: paced chirping, as far as I understand is a clever extension of this idea, that suffers from the same problem, that packet pair measurements work great in the lab. less so over the internet.

Side-side-note: you can extend the same idea also and use packets of different length to measure capacity. I did that accidentally as part of my old ATM over head detector approach, where the linear fit of RTT as function of ICMP packet size correlated really well with the inverse sum of uplink and downlink capacity IIRC. Which was neat, but useless and it required linear fitting, if only due to ATM/AAL5's peculiar quantization issues, but I digress.



I'm interested in the idea of measuring packet timings to our customers as a way of detecting short-lived issues, which I find excessively annoying to detect and quantify (;-))

        [SM] Ag, that might actually work, because you are not aiming for "over the whole internet" but over a well known segment mostly under your control, no? I assume you address this with an ISP hat on, not with a content provider hat on?

ISP-like service provider, definitely. We're a kind of payment processor for folks who pay for their web sites by having us auction off ad space.  I'm actually in ML/Ops, but have an interest in anything that can mess with our performance (;-))


Regards
        Sebastian

*) e,g. measly DSL links essentially use ODFM and send quite a bunch of bits in parallel, so even if a DSL link is the capacity bottleneck, our back to back pair might traverse that link in one fell swoop fooling us about the available capacity.



--dave

--
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest

dave.collier-brown@indexexchange.com |              -- Mark Twain

CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.bufferbloat.net%2Flistinfo%2Fbloat&data=05%7C01%7C%7C59245dd9ce2f42dae74508db23f3c839%7Cb07c069022b843668d8d7b845d088e18%7C1%7C0%7C638143302165333406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m7iX24gQCPmu%2FLd4%2B5ogy2GGTsnK6FzQw4EwH59ooDA%3D&reserved=0


    

    
-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com |              -- Mark Twain

  


--------------Rgrm6atuzZ0lAQmcfadd9hq6--