Re: [Pce] PEDF / PIFO / ... (was: Re: [Detnet] new draft on segment routing approach to TSN)

Yaakov Stein <yaakov_s@rad.com> Tue, 09 March 2021 04:34 UTC

Return-Path: <yaakov_s@rad.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8F93A0F02; Mon, 8 Mar 2021 20:34:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rad365.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOqduMsxkNta; Mon, 8 Mar 2021 20:34:23 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50059.outbound.protection.outlook.com [40.107.5.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FDEA3A0EFC; Mon, 8 Mar 2021 20:34:23 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T5FO7ITnq/kx4TqegDNjtN/b1Swk+V6wcVEnIydDaJoD+dz+FmkCCzduAE5fwteDsyjZGmCp8hOLr8rO/7CwaQ2huxyX3q722XtrA+CxsPNV7Q2LdU4BdKWTMuihztkfkoE2MTgkjdDvR6aZUzxODhNqEoJTsj/q8Z5slNR4xVCHYW3ntUR8X5fpFxY20U5nVzJfs9AvmeRKUjzUjYH/XhoNNrLaV0oVcmu5FWbNlJZOAf/uPRGAIQl5LkzkS7ixy9FT6/fDSS0a7xkKDoeJl29cNXnLSODW6zKqKdwelHvt0+7Fm4IWZc4yvz0WMVqDhWBvzYMRJQqw/jB2L0XgSQ==
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-SenderADCheck; bh=x+c9jBN9FNxUtd3BQQjKJiwg+w+qIxHFm61wAHRT8fU=; b=Pj/TSMl4EumZdK9P+bdsL+DV1RQzjgp/+1FyySaclMVAn6+RybXHrwYopCGiDhBRtu0UAK90NDMuZdtNXRgne/DdPIAsTdCXMhp8uYZbG9rjF8d2k4tuzkr312ZlWDH1zNboxed1Y70TqJ7rsWR1VNyf42OamKxtonArMxdGMFTlz186BSxbCZUJDNje9c5zlqUJtIphT99ayve7/b0ZfhC4mYPXUNTX63hnzJJaITB1CX/cg1B+S08wkDanUyY1PqGhjkyn3dgc6oGC0/O46ovX4C+P0r5Io32+/2F1VhJE2M3/xDzBgtMSNof+bnA/xiw8w0b+1UcLLUNhjuxOWg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rad.com; dmarc=pass action=none header.from=rad.com; dkim=pass header.d=rad.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rad365.onmicrosoft.com; s=selector1-rad365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x+c9jBN9FNxUtd3BQQjKJiwg+w+qIxHFm61wAHRT8fU=; b=Y0I6AxUXHPBsSZmscbkgoWp08rNBkScv5q2yuQqCWiRFpq8+KqX5ODAoZgYSMQFivQj19U/LYPP3vVwzIu4y9mnrwcPwzCle0UiNjMGiMM8KMa6FStR80vWyT3vHcXCX0+j76u0yQju9FIufDnMFO+nWQxL412jntn+uZWl/fBc=
Received: from AM0PR03MB3522.eurprd03.prod.outlook.com (2603:10a6:208:42::23) by AM0PR03MB3969.eurprd03.prod.outlook.com (2603:10a6:208:77::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.26; Tue, 9 Mar 2021 04:34:20 +0000
Received: from AM0PR03MB3522.eurprd03.prod.outlook.com ([fe80::10eb:24f4:1a5e:bc0a]) by AM0PR03MB3522.eurprd03.prod.outlook.com ([fe80::10eb:24f4:1a5e:bc0a%4]) with mapi id 15.20.3912.027; Tue, 9 Mar 2021 04:34:20 +0000
From: Yaakov Stein <yaakov_s@rad.com>
To: Toerless Eckert <tte@cs.fau.de>
CC: "detnet@ietf.org" <detnet@ietf.org>, Haoyu Song <haoyu.song@futurewei.com>, "spring@ietf.org" <spring@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: PEDF / PIFO / ... (was: Re: [Detnet] new draft on segment routing approach to TSN)
Thread-Index: AQHXFDkx7yt1lj+bJU6wgn6XxpWNAKp7EGYg
Date: Tue, 9 Mar 2021 04:34:19 +0000
Message-ID: <AM0PR03MB352271EFBE452657CEED088AE5929@AM0PR03MB3522.eurprd03.prod.outlook.com>
References: <AM0PR03MB35228092287B38B95D7056F7E5809@AM0PR03MB3522.eurprd03.prod.outlook.com> <DM6PR13MB2762033C6ACECC4A816830AC9A969@DM6PR13MB2762.namprd13.prod.outlook.com> <AM0PR03MB3522BD9D4D0A3134FE16B49FE5949@AM0PR03MB3522.eurprd03.prod.outlook.com> <DM6PR13MB27624F07A612BDCF98A8C92F9A939@DM6PR13MB2762.namprd13.prod.outlook.com> <20210308163623.GA58143@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20210308163623.GA58143@faui48f.informatik.uni-erlangen.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=rad.com;
x-originating-ip: [176.230.181.29]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 27ff31d4-7c2c-4cc8-7ef2-08d8e2b49b4c
x-ms-traffictypediagnostic: AM0PR03MB3969:
x-microsoft-antispam-prvs: <AM0PR03MB396968F20608FBC62E241900E5929@AM0PR03MB3969.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3968;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ayKNnBVJdxZcp1kzOhTGDYPkVN9Iz5cSRTHTs+M+92MiUjLBl26LZiR5Q4SgIDWHArk4KAAWFbWY5WkkMNE6jNOh2cBwrKfnXch5B2aYHPik8OszDK8ztatwRrs7hORo+3a2QCRCp3dbqleVnLKatrQ+NF1XzdJljU8IxG69ZyAXeYv3GYdWqkOBaijTl+lsOHBQC4C6ZMYyEyUtNlGQnQjA3OKCskHhwEdI52kdum9x4eKu4oK01oTCgv9H0RZ45Wx9wMk12x/Z65JELcR19uzFzvHW7ZVxb2DB0f205hETIIYhA3xJqxSETbJe4WJfBfX6pNmQX77ytDSBXY1hkiYJUAwzeYlFvICu7PGhPFdoTJSWOxXTAFd6Z4TewKDUTer55ep+je+/aEdSKmQXwiEywyK0yzZDHIi3dUPoMpqUoexNFvd18slh1taP7j2iCjbZ0dpqrw5XmxNztZIoayQT+NY2xfbieiy6s39yo9tXmytn4UcyWwp5Ou+DSJWEiaze9Jnq8Q4kBGUdxZ/InF1UQOwddJJyfPbk6zdojUrYlwF7sI/NvIzb3W5oa66cskKBCbUHjX7N+TmVpRab8hp/PeMNZgRFYjaQkbRDRFw=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR03MB3522.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(39850400004)(366004)(346002)(136003)(53546011)(6506007)(55016002)(5660300002)(66946007)(52536014)(76116006)(54906003)(8936002)(9686003)(45080400002)(33656002)(71200400001)(66574015)(2906002)(186003)(966005)(6916009)(86362001)(64756008)(478600001)(4326008)(66476007)(8676002)(66556008)(66446008)(316002)(83380400001)(26005)(7696005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Hjske8XlQrshIlBmnwApUQxB7u3s+tlHFUnxu9p++rK6ozgtksrGvcOsTeYc?= =?us-ascii?Q?8DRtKZelnclczx/wlWHRZa3Jugv7vkZyW36TvsAzOaohe8pz1ZcBumvJ/EhN?= =?us-ascii?Q?qy3kkKRuBT1X7lCnnUdrDV9DLtsxcKgRzJ9Kh4p/43X0qWEkjCo6vhnewMQw?= =?us-ascii?Q?4F/w6rOoDck+BP5w667BZ0U9TsyB3+FRTt4dSChF6cPfphTWD6VYFrJOVjYJ?= =?us-ascii?Q?MniU5rbweP8Uy6DP0Rhlin7YjHz7UY4o1g5LXvSnM9fBnK+It1QPFZL0fFem?= =?us-ascii?Q?cGV8TOO+EzbtfPQlefJytf1kLHaL2dq2ee64sEDj+Hv6Pg87PI4LEyCAm271?= =?us-ascii?Q?awXAF9558nCEfMaz6PZM9L9lEgnyzNXlsAdx9jxVUparzflhO6wQ4mtpLP3E?= =?us-ascii?Q?i8rEml4UdkdT+bkIgmVlhB0TcTCPxnSjQSyQ2HeZpd7EnNZ6D6um4eftpopi?= =?us-ascii?Q?1B9nRmMyVx/HiDoOvfzPKRUEIY+XO1hGd+mr5zj56nYPWG4N/tlBAs0Nfbze?= =?us-ascii?Q?DfQCPshOOfG8V1oEbXNEePQ+/yZYmyggcZ/+VgIEhJcI9eugsQPbZAdGwV67?= =?us-ascii?Q?UqVmqiN3PSEtmWPDJ9WJjCjzNQORfeWBhNHCdolELfiIBfgAQvXlx85SXOYF?= =?us-ascii?Q?yozGm0j2aZ9MRf6y9wrA7d/ltKq2ISk+lx0BiMqNaSt1h6Be7yrC1Tl49bHJ?= =?us-ascii?Q?dzoNxycyIHuh9EPuKyEIeSqSB3BdVsWEBVB/a8Q6Pqb/UCUJ5W0sa92BtssG?= =?us-ascii?Q?tGnHbGWJ1rdpOzqv56ULLsrq+DiYP9OdsqqfILDfx2A8KSxFvT9CKrK3WObN?= =?us-ascii?Q?evvEDPXE3AFfIzXhhLKfPSwwBruzDF4fLn4s/aKZyO2AytsSPnoP7gzzz7Qa?= =?us-ascii?Q?Ghf3qEDOZY2n5WRpka1WMwEXjkdjQ0qIOYodpyZGpARxFCdTURR4iX3Q+AAQ?= =?us-ascii?Q?K56X5JzjDUYjLO8f+GMLrVQwfehU7iQwfR26iAb0bovT8sgJ5YB5qBF9z73e?= =?us-ascii?Q?4N0Mx3FmZjuTzgES0yRZBrCxstovGkr5BUHWmhVJ6MOo6iz5dsIAQS61Phlr?= =?us-ascii?Q?CwcomAm5M0Sxu7OnwidzJS02uS6UzIAPcYj4ZnkGKurf9TRFvUMYXWQTQJzV?= =?us-ascii?Q?uwE9ZaVGfyAke5QXBssYEgrUuu6LMh9uaivL6XkTroD/spsOV4lhE4+xPFTy?= =?us-ascii?Q?0W6xDE0SWTWyshPSWVutIAGACzdsHTcWBFf2J/twX+uHRbbHGn62Tm32HIzx?= =?us-ascii?Q?O8tLA6xR0p7Vm8vzc5+QUtjbO6ucrlFSqS64yInNUYCxQ35KCAroKN7qr9VC?= =?us-ascii?Q?+FEUYMz0tiqF/PmTql8LviMb?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rad.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB3522.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 27ff31d4-7c2c-4cc8-7ef2-08d8e2b49b4c
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2021 04:34:19.9568 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cJ8rqAI++7WtU8PHNMZUGrxFduW5kyMfOyB0yV/sgtR7e+wo1YwJuCEuUuWkSvaF7OOBjWrr0IspMvc4NRyM1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB3969
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/T78Wfx2DgWsngPCa7rMthx4tlYg>
Subject: Re: [Pce] PEDF / PIFO / ... (was: Re: [Detnet] new draft on segment routing approach to TSN)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Mar 2021 04:34:27 -0000

Toerless

I describe PEDF in the ID. It is a twist on the combination of strict priority and EDF.

Basically there can be multiple time sensitive flows with different priorities and non-sensitive traffic as well.
With PEDF one first looks at the TS structure with the highest priority,
however, one doesn't take the packet in the highest priority (like in regular strict priority),
but rather you check whether its deadline is closer than the maximum packet clock-out time from now.
If not one checks the next highest priority, with full knowledge that one can send another packet and still make it back in time.

This can be extended to WFQ as well.

Using PEDF loosens the requirements on the optimization.
In fact, PEDF and the simple calculation on each flow separately
usually outperforms EDF and a more sophisticated optimization calculation.
(I don't yet have an analytical explanation of this...)

Y(J)S

-----Original Message-----
From: Toerless Eckert <tte@cs.fau.de> 
Sent: 08/03/2021 18:36
To: Yaakov Stein <yaakov_s@rad.com>
Cc: detnet@ietf.org; Haoyu Song <haoyu.song@futurewei.com>om>; spring@ietf.org; pce@ietf.org
Subject: PEDF / PIFO / ... (was: Re: [Detnet] new draft on segment routing approach to TSN)

> Yaakov wrote:
> I've heard of PIFO (Push In First out) but not PIPO. Is this a typo or something new?
> I agree that there are mechanisms that are optimized for hardware, but I have come up with a very nice hardware implementation for PEDF  and prefer to find hardware implementations for optimal schedulers, rather than to determine schedulers based on optimal hardware.

PEDF ?

There was a long debate in the congestion control technology in TSV about the scalability issues of flow-aware AQM mechanisms and AFAIK, ultimately, the AQM mechanisms that won out where the ones that did not require this (such as PIE).  We also had round 1 of deterministic services (if i may call them that) using rfc2212 with RSVP fail because of real or assumed infeasibility to scale on multiple dimensions. IMHO it actually failed also because of assumed infeasibility becasue there was no good analysis and documentation of what actually could be made to work (badmouthing...).

>From this experience i can only recommend to make sure that we do understand what and how something is feasible to be implemented a what scale and speed. 

For example, i am not aware to have seen general purpose EDF hardware at scale. But i am very interested for any pointers. On the research side, this one is the oldest one for PIFO i know:

https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fweb.mit.edu%2Fpifo%2Fpifo-sigcomm.pdf&amp;data=04%7C01%7Cyaakov_s%40rad.com%7Ccb4381151b5f494cc2ce08d8e2505295%7Cf9047108cc2c4e4897a343fad1b3bf9d%7C1%7C0%7C637508181910510455%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LCK5i%2BmLewtZdjJIK7RlDPFqIRONvgefZxaX1f91ckw%3D&amp;reserved=0

[ i am of course mentioning PIFO because by using deadline as the PIFO rank, one has
  a simple approach to implement EDF].

In this work, if i remember my analysis correctly, the scale still depends on the number of flows and the ability to identify packets to flows (need to read it again though).

This _may_ be acceptable in specific use-cases but should IMHO be well understood and documented, especially when the view from the outside is that by using e.g.: SR packet headers it is "looking" as if there is really no per-flow scaling aspect to the hardware requiremens. After all, the idea of source routing with SR and having the state in the packet is to eliminate the need to have) and scale it in the router.

Cheers
    Toerless

> >> Sorry that's a typo. I mean PIFO (although we do have a paper under review using the name PIPO). Yes I agree those are just abstract primitives. The actual implementation, if customized to a particular algorithm, would be simpler.
> 
> Y(J)S
> 
> From: Haoyu Song 
> <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
> Sent: 05/03/2021 22:46
> To: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>; 
> detnet@ietf.org<mailto:detnet@ietf.org>; 
> spring@ietf.org<mailto:spring@ietf.org>; 
> pce@ietf.org<mailto:pce@ietf.org>
> Subject: RE: new draft on segment routing approach to TSN
> 
> 
> CAUTION: External sender. Do not click links or open attachments unless you know the content is safe.
> Hi Yaakov,
> 
> Just got a chance to read your draft. I agree with the comments of the others that this is a very interesting work. I'll just add a few points.
> 
> 
>   1.  The use of clock time as deadline requires network synchronization, and accurate measurement of per-link propagation time, which can somehow limit the application scope of this work. Alternatively, one can simply budget a device latency which require a router/switch to obey. In case the overall budget is evenly divided by the hops, a single parameter is enough. Of course, if one wants to customize the budget on each hop (which might be necessary considering the different capability/capacity of each hop), a stack is still needed.
>   2.  Mechanism should be provisioned to track where the timing requirement is violated and by how much (e.g., using timestamp or flag). This would be very useful for troubleshooting.
>   3.  Recently programmable scheduler research has proposed several primitives such as PIPO and PIEO and provided feasible hardware implementations. The scheme proposed in this draft can easily fit into these primitives.
> 
> Best regards,
> Haoyu
> From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> 
> On Behalf Of Yaakov Stein
> Sent: Tuesday, February 23, 2021 5:14 AM
> To: detnet@ietf.org<mailto:detnet@ietf.org>; 
> spring@ietf.org<mailto:spring@ietf.org>; 
> pce@ietf.org<mailto:pce@ietf.org>
> Subject: [spring] new draft on segment routing approach to TSN
> 
> All,
> 
> I would like to call your attention to a new ID 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-stein-srtsn-00.txt&amp;data=04%7C01%7C
> yaakov_s%40rad.com%7Ccb4381151b5f494cc2ce08d8e2505295%7Cf9047108cc2c4e
> 4897a343fad1b3bf9d%7C1%7C0%7C637508181910510455%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C1000&amp;sdata=KhdBd9Z2XCTVUvweatNWyCgwZDVKssHJF2W%2Fz41Q1uY%3D&amp;r
> eserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A
> %2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-stein-srtsn-00.txt&amp;data=
> 04%7C01%7Cyaakov_s%40rad.com%7Ccb4381151b5f494cc2ce08d8e2505295%7Cf904
> 7108cc2c4e4897a343fad1b3bf9d%7C1%7C0%7C637508181910510455%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C1000&amp;sdata=KhdBd9Z2XCTVUvweatNWyCgwZDVKssHJF2W%2Fz41Q1u
> Y%3D&amp;reserved=0> which describes using a stack-based approach 
> (similar to segment routing) to time sensitive networking.
> It furthermore proposes combining segment routing with this approach 
> to TSN resulting in a unified approach to forwarding and scheduling.
> 
> The draft is information at this point, since it discusses the concepts and does not yet pin down the precise formats.
> 
> Apologies for simultaneously sending to 3 lists, but I am not sure 
> which WG is the most appropriate for discussions of this topic.
> 
>   *   DetNet is most relevant since the whole point is to control end-to-end latency of a time-sensitive flow.
>   *   Spring is also directly relevant due to the use of a stack in the header and the combined approach just mentioned.
>   *   PCE is relevant to the case of a central server jointly computing an optimal path and local deadline stack.
> I'll let the chairs decide where discussions should be held.
> 
> Y(J)S
> 

> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fdetnet&amp;data=04%7C01%7Cyaakov_s%40r
> ad.com%7Ccb4381151b5f494cc2ce08d8e2505295%7Cf9047108cc2c4e4897a343fad1
> b3bf9d%7C1%7C0%7C637508181910510455%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sd
> ata=v3Dh%2Bq0%2F8eYutLOjnkz0Aa%2BvieQW8CoRhhbv7JfN77c%3D&amp;reserved=
> 0


--
---
tte@cs.fau.de