Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 14 November 2017 19:29 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3888124BAC for <6tisch@ietfa.amsl.com>; Tue, 14 Nov 2017 11:29:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 yfYLC_0Gw2yc for <6tisch@ietfa.amsl.com>; Tue, 14 Nov 2017 11:29:10 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAF91288A9 for <6tisch@ietf.org>; Tue, 14 Nov 2017 11:29:10 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8AFF720008 for <6tisch@ietf.org>; Tue, 14 Nov 2017 14:30:48 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8B74782B23 for <6tisch@ietf.org>; Tue, 14 Nov 2017 14:29:09 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <20396.1510678103@obiwan.sandelman.ca>
References: <CADJ9OA_cKxWZLvfpNXhjNgL1HurfdK-Oqj1M-wU9pK5t+1kU4g@mail.gmail.com> <20396.1510678103@obiwan.sandelman.ca>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 14 Nov 2017 14:29:09 -0500
Message-ID: <32033.1510687749@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/TBYirfs7OTdyLA9rcTEckqt1E2o>
Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2017 19:29:13 -0000

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    >> During the WG meeting yesterday, we discussed using DSCP bits as a way
    >> to identify join request/reply messages. We talked about mapping, in
    >> the minimal-security spec, the different DSCP values to scheduling
    >> behavior.

    >> But you indicated the DSCP bits would be in the inside IPv6 header.
    >> That doesn't make sense to me, can you please provide more info? The
    >> outside IPv6 header looks to me like the right place to put the bits.

    > I thought it was a typo, and I passed it by.

    > Why in this non-storing, RPL-aware situation is there even an IPIP outer
    > header for traffic from the proxy to the DODAG root?

Since I re-read Pascal's answer (in the light of my "day"), I now see why it
can not go into to the outer IP header, because we didn't not plan for it.
I thought that in 8138, that if we didn't need an outer IPIP, that we just
used 6loHC (rfc6282... https://tools.ietf.org/html/rfc6282#section-3.2.1)

If we can agree that this is the way, then I think we also need to agree that
certain AFxx would be assigned to available bandwidth, and not cause 6top to
allocate any additional bandwidth.  This does not really fit "AF" Diffserv in
some ways (which in some ways to buffer/delay rather than drop...).

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-