Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS)

Stewart Bryant <stewart.bryant@gmail.com> Tue, 08 September 2020 16:22 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4B53A05DE; Tue, 8 Sep 2020 09:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 d-1P_VmFY6S2; Tue, 8 Sep 2020 09:22:46 -0700 (PDT)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34A93A14BF; Tue, 8 Sep 2020 09:22:12 -0700 (PDT)
Received: by mail-wm1-x342.google.com with SMTP id y15so5154693wmi.0; Tue, 08 Sep 2020 09:22:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rzkSPj3jctXF1OV259G5PYrkn6ZAqUd2nmVQBvHreAE=; b=OXhC0RQjmm0ZK+pGqkr5jlQpXYN/MQ/sIrOYTxfdJfgs4h0tkrd7uiXky9LeOCuXEm 24cQeSfDbwy9QBjbUIKot6kNzcaS0XsgILQhhZDd1K92obP48Tboj6DoFDszdOoF3oI2 QB+w1UGhsSSzwdcVYYdWg3lbQsgE+3pn1p8Y5CfJHWV4BPfrmkFW7ZuLU9fAYlPxGFnb fa0UOZ+GAgIJNTl3ylvhLXLniC6bK4+Cc0A1XhWa/N/9XjSifgO2AiyTw/OJztd4KZp7 O/wB69Sa/boUIVjuXdDDu3OmZNxw2ApEqQMW67gek05+7w+dsxoPnsCzHOYmXbhgDX8u E8yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rzkSPj3jctXF1OV259G5PYrkn6ZAqUd2nmVQBvHreAE=; b=HR2O4gD0rLMPsusHH6zaVsd55iwXCd9a6iNmdok3FOfbSN2Co0EPQfA0TSJyREUnBt DEk6pkiCcqXBAqR5seVLYZMv8ONrHp4T8T04AP0e3hEpEo7GoYHGbsYJdzbZuzdXr5jW Ybe/yXuREAB2SutWy6P/ZNldPA4ilrHpixKDxqxWe2uKfpR+BrKO1HxBlhKyUyYylvxy RhgWVKXKUh0y0srwZoxBRwybQ6Swbfk3hjQgzC4L29x5YWrzYINWH7K7En0gucjKj0B3 0lmdrc3NkfwA7ze7LLBb7iVnY/r2Cx8MPunohv4V4gnNzRMsiwM08p/DTxUNEMZDszuU NIiQ==
X-Gm-Message-State: AOAM531nYMJAHXkrN5PGLIGjuouNq3FoR/wgnEWa906+QNmqe6IKTy+4 u7ZItsdLm4mcXWorO7HnWPc=
X-Google-Smtp-Source: ABdhPJzgcY1oSMx1/Fb3dkBjTkxOJK9Gx1Sm2bmpahnpdUcNQvpipsOF9hOBW3BvSteHWu0OQtAR5w==
X-Received: by 2002:a1c:2002:: with SMTP id g2mr314144wmg.122.1599582131284; Tue, 08 Sep 2020 09:22:11 -0700 (PDT)
Received: from [192.168.178.46] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id y5sm24775303wrh.6.2020.09.08.09.22.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Sep 2020 09:22:10 -0700 (PDT)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <DD83469A-312D-47A3-AEBC-4539B9F36B25@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0A6E29ED-FD3A-4056-9DB8-4CD8701F28F7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Tue, 08 Sep 2020 17:21:39 +0100
In-Reply-To: <159957776121.26189.12459072134609921207@ietfa.amsl.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, The IESG <iesg@ietf.org>, draft-ietf-detnet-mpls@ietf.org, detnet-chairs@ietf.org, detnet@ietf.org, Ethan Grossman <eagros@dolby.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <159957776121.26189.12459072134609921207@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/IntqIPEjFb0nltdoY9q_qmC1BIY>
Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2020 16:22:49 -0000


> On 8 Sep 2020, at 16:09, Magnus Westerlund via Datatracker <noreply@ietf.org> wrote:
> 
> So both of these section discuss the use of the sequence number for removing
> packet duplicates and handling reorder. As the text discusses there can be a
> configured limit for how deep the buffer and state are for performing these
> operations. We all know that the implementation of this will have a practical
> limit in both buffer space for reordering as well as state for tracking which
> sequence numbers that have been forwarded. I think that should be more clearly
> expressed in the document that these practical limits exists. Thus, the
> implementations will have tracking and determination of what are new packets
> (increasing sequence number within a window higher than previous largest seen.
> And consider sequence number form currently highest seen and a bit backwards as
> older packets. Thus how this is implemented will impact how this acts in cases
> of disruptions of the packet flow. Thus, I wonder if there is actually need to
> be  a bit more specific in how classification should be done. Especially if the
> wrap-around of the sequence number space approaches a small multiple of round
> trip times for the path which is likely for the 16-bit space.
> 
> Then  sections fails to discuss how the duplication removal, the reordering
> buffering and bound latency interacts and affet each other.  So if the latency
> is bounded then the reordering has an hard time limit for the maximum delay. If
> there is a boundary for reordering then there are no point in de-duplicating
> packets that will not be forwarded due to the reordering. And even if there are
> no bounded latency the reordering buffer size will still impact the depth of
> de-duplication. These practical limits will also be limitations on the
> guarantees that can be provided.
> 
> Thus, from my perspective there is need for more text on the requirements of
> the implementation of these functions and their interactions of creating
> limitations.

The text seems to line up well with the work that we did on pseudowire sequence numbers and we have had no reports from implementors or operators that we need to increase the text and provide implementation guidance.

I am always worried about overprescribing the operation of such systems since it is easy to rule out legitimate implementation optimisations, or inadvertently prevent the use of the technology in some way that we have not yet considered but which would be valid.

I would argue that the buffer sizing, constraints and management is more properly a discussion between the vendor and the operator.

On latency we are not in this design providing precision latency management, just best effort mitigation of the natural latency of the network. This may change if we introduce queue management or other services, but I do not think we are there yet, and suspect that once we get to latency management we will need more metadata in the packet.

- Stewart