Re: [trill] [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10

Donald Eastlake <d3e3e3@gmail.com> Sat, 03 February 2018 02:18 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19F5126DED; Fri, 2 Feb 2018 18:18:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 7mQAPpHHBiKT; Fri, 2 Feb 2018 18:18:09 -0800 (PST)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (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 E04D612420B; Fri, 2 Feb 2018 18:18:08 -0800 (PST)
Received: by mail-ot0-x234.google.com with SMTP id a2so10725163otf.2; Fri, 02 Feb 2018 18:18:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LOGiNDTT+IWErWlIXJcQHAJZROZglYQGg3FjF0N4JzI=; b=N0SPhmupNRbQxZuhKZjo/nqAES2gXQTTpfALIqiyeR3Z3jj5Pw18U9dSLuVI0tD6I0 BOoULjK6cTtdQAPWu4m66EcyNuTXOnj2vMVqofAxaVJKQKD1fLwuRGXXL2m7yCbTQVp8 X472jitB+dDMhl0uGNCRK2YnjxVqX9y8mngedYS5M707L4v2zMiFtbPiD8gHvyb+I9xZ D3H/nt5BwORHm3e9rvWNBGa3/dRMH7bEnLn9vJNXzagtdpO31PWBQEtXjIGSr08b+m/r uYMqGfihQNYn3jvJYgGt+pZR7rXQipgJ6UZqFSZLQ3gthlsMy+zPijWERjBI81J0rQUp 2VyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LOGiNDTT+IWErWlIXJcQHAJZROZglYQGg3FjF0N4JzI=; b=eyfeMqrm4kJCsNqZRRtQMK+xcra5YoB4aiMurq6E1RINhclvxy+/SOULttSeK4aU4/ ax0NHPp3AmBcYgzCSf9Jn6ok0IB9AJjRWB+vFTsGKKf087kg/7uYgoTwSFWdV7nEGdVE QUA5PhZ+cNEqcno1nEif/W2blaHABCng/s1tknqohuFHS0oBT+e/SO8Xny4l8V7UZuDT mR5mH9FgPhdC40Kpr1B7U73Mvvl1Y0P1cNOe9KTR8v8cDYwieGT92ipMCs3KhBkszi+v P9fL8KGAYQ//0F/S365BOk4SezFlOQOvTZ3pZ7JcENXxaRpWVLt3Zzbk72Ym92CpruB9 q8Zg==
X-Gm-Message-State: AKwxytfzNpFMveryLahfoBIpB6jYa1zzYx3OCfkpGLasRqZLArVFTih8 IDpQhd5T45skAYNrrgoBr4z/S+IpELieoRkGlgM=
X-Google-Smtp-Source: AH8x225mQYJrYWEwODuo4nxCjAJpl2/LrRvy+pg0dlLL4SKtul1rtlmCTyk7KupiJ/0MXW7BsPDm5ryLPrWaJ/dEuAQ=
X-Received: by 10.157.60.246 with SMTP id t51mr14846777otf.135.1517624287872; Fri, 02 Feb 2018 18:18:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.67.205 with HTTP; Fri, 2 Feb 2018 18:17:52 -0800 (PST)
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FFCA9F0@MX307CL04.corp.emc.com>
References: <149754795560.13109.17521244075940607817@ietfa.amsl.com> <CAF4+nEG-28weDot9R9Z4-05PX1tzBoKZSOHu8BJY2GiRzOv0nA@mail.gmail.com> <52E4A8FC978E0241AE652516E24CAF0029AC2251@ESESSMB103.ericsson.se> <CAF4+nEEhaY+gtyjhVN1uzwgJ8m5oy1VU3urdH_hh-2KYV+NXLQ@mail.gmail.com> <CAF4+nEEaJr7RwAaQx59fTvAhh0qy1NRqPx4HREvzGPRHqdx++w@mail.gmail.com> <e4cb17c2-188a-4201-8803-34437e38c36b@ericsson.com> <CE03DB3D7B45C245BCA0D243277949362FFCA9F0@MX307CL04.corp.emc.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 2 Feb 2018 21:17:52 -0500
Message-ID: <CAF4+nEH_Jy+zKiQ5_W_46pwdt2PUg-ahcCpnQGd=PejOXYdfcg@mail.gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-trill-over-ip.all@ietf.org" <draft-ietf-trill-over-ip.all@ietf.org>, "trill@ietf.org" <trill@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/9LXNOmx2IvBSybCM3ZqlCOH_570>
Subject: Re: [trill] [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Feb 2018 02:18:11 -0000

Hi David,

On Fri, Feb 2, 2018 at 12:20 PM, Black, David <David.Black@dell.com> wrote:
>
> A couple of Diffserv-related follow-ups to Magnus’s comments:
>
> [1]
>
> > I don't really understand this change. Now you have priority 1
> > which points to the proposed new mapping for Lower than Best
> > Effort, being the least prioritized. Then priority 0 intended to
> > be more prioritized is CS1 which may still be lower than best
> > effort (thus basically same as prio 1), or end up being receiving
> > a more prioritized PHB than best effort.  Why isn't 0 mapped to
> > best effort (000000)? That appears that it would provide a more
> > consistent behaviour.
>
> +1 – zero should be best effort in all contexts.   Moreover, the
>      table has additional problems:
>
>
>       TRILL Priority  DEI  DSCP Field (Binary/decimal)
>       --------------  ---  -----------------------------
>                   0   0/1  001000 / 8
>                   1   0/1  000010 / 0
>                   2   0/1  010000 / 16
>                   3   0/1  011000 / 24
>                   4   0/1  100000 / 32
>                   5   0/1  101000 / 40
>                   6   0/1  110000 / 48
>                   7   0/1  111000 / 56
>
>
> The entry for priority 1 is inconsistent – 000010 Binary is *not* 0 decimal.

Yes, the decimal version was not updated when it should have been.

> If 000010 was an attempt to anticipate a possible TSVWG assignment
> of DSCP 000010 / 2 as the default DSCP for less than best effort
> traffic, this serves as a practical lesson in why that sort of
> attempt to predict the future is not appropriate for a standard.
> While that DSCP was suggested in some earlier TSVWG drafts, better
> understanding of some unfortunate “running code” in the Internet
> that zeros only the most significant 3 bits in the DSCP has led to
> TSVWG’s current direction (as of the Singapore meeting week) to open
> up the pool of DSCPs that end in 01 (xxxx01) for standards usage in
> order to assign either DSCP 1 (000001) or DSCP 5 (000101) as the
> default DSCP for less than best effort service.

Thanks very much for your subsequent message suggesting specific
wording a copy of which is here:
https://www.ietf.org/mail-archive/web/trill/current/msg08112.html

Your suggested wording looks reasonable to me.

> > "All packets in a particular TCP stream SHOULD use the same DSCP
> > codepoint or packet re-ordering may occur."  > I think that SHOULD
> > > is a MUST. You get no benefit from trying to send different
> > packets > in a TCP connection with different DSCPs.  > It will
> > really only > result in reordering, and additional
> > retransmissions. Also the TCP > stacks Head of line blocking will
> > also not really > allow any > received payload to be released
> > early. Thus, only downsides and now > gain to use different DSCPs
> > for a single connection.
>
> +1, and see RFC 7657 for further discussion, including this text on
> why having a single TCP connection use DSCPs that vary only in drop
> precedence (i.e., aren’t supposed to cause reordering) is pointless:
>
>
>    There are situations in which drop precedences should not be
>    mixed.  A simple example is that there is little value in mixing
>    drop precedences within a TCP connection, because TCP's ordered
>    delivery behavior results in any drop requiring the receiver to
>    wait for the dropped packet to be retransmitted.
>
>
> There are no “MUST” keywords in RFC 7657 because that RFC is
> informational design guidance, but its guidance justifies the “MUST”
> that Magnus suggests.  I would also suggest citing RFC 7657 as an
> informative reference.

Seems reasonable.

> Thanks, --David

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com