Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 19 October 2017 22:38 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2A4132355; Thu, 19 Oct 2017 15:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 c5wT95K2Gcmh; Thu, 19 Oct 2017 15:38:55 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 BAB6E13308D; Thu, 19 Oct 2017 15:38:55 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id i5so8082145pfe.6; Thu, 19 Oct 2017 15:38:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2cKaTTr7XZ82Znp26cJPO34laTTBTd4Cd7jdceQM8PY=; b=YRbBClpE0L4ybJFqyYNnoA3tuoKf5pfE553Ap8arP55YxwZFLUnMTTpD4Kpfj7jKQ+ W3wgmqYZ75QgvCm2LMbhXCpRUkv9mHLcCmaEsBVTU7cLMlL+hM9+D+HwL622F4KJqy4i t5ik9v3wXLpiUPT0GLaVMSRDBB9qgj0+6YMXxWe0V18OoXHZlUL5ngpWb7rEHy7H4RdD IFLV1Qjthdi7AJwnAojkPXDOAD3xZ3xG5A0f2jYAA3xcyfR/gxq4qoiNFsoHQJvG1uIx gWTvIuXKq7xBuh/J3eFgF8OXle4Z6lXOmFb4iWy/zqqsiUgi84LdrA5IVjMSL10Nu3yR 9+Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=2cKaTTr7XZ82Znp26cJPO34laTTBTd4Cd7jdceQM8PY=; b=LnzpAiMzlv/G8slBG/UgM9qbrxgcPfhF2a/SQ0AwXEzXLKJpHNtG2lXePDgS3+hvg4 qqh0l40uk7TFcdVc5Y5Ta+pUNJjPycCNnv1o+eRhEyuZ8bgBe6DPpGcWU2OGiC0KaCGG J92YqRVk5M5K3VKQZXXJ6P7veLUEbHQKKjIAobB5+0/rz2Oa0vEAvWSHfkpAKIaJ4L2W 58wfNrmOLm8eLMBtjcINWlQgQc3+Ds1PLyLkevu2rBo5FjbVD42/FkDgPnnq2GSMd2g2 GO0g2+wmdhQeTi9vsow7KjPOlJ0xX21me8gdVlvsbVcM9fF149mZ6sWwKotmkp6mqA0b uIgQ==
X-Gm-Message-State: AMCzsaUjC9f3qpTEVjupCl8SHgb3IKrZvojdtA5t9JNeyKiSd5nu/RnB +yeTLLrdMS2VlmzirD5FQLzGBw==
X-Google-Smtp-Source: ABhQp+RFtYJsLP6ZdpCbJC57QvaZ2Z3g9dbU1L2dqCxTXFVjcYMIgstZeKAWnXLVI542sEqgMKHErQ==
X-Received: by 10.84.129.4 with SMTP id 4mr2564159plb.320.1508452734971; Thu, 19 Oct 2017 15:38:54 -0700 (PDT)
Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p14sm25109982pgr.51.2017.10.19.15.38.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 15:38:53 -0700 (PDT)
Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt
To: tsvwg@ietf.org
References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <cc11634a-b5a2-88b9-f36f-82b3fd9d8d70@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <a4da4b26-6402-ad0d-a5f5-5bddc192b8f7@gmail.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <CALx6S341v1zd2Q9bts8-zrKxU59kieJTJJ=nHQ5w4oQZg=t_cA@mail.gmail.com> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <CALx6S37wLvuJ9tUGjYmzm63eq_bxq0jXSEgfCtH_2i74SvrbLA@mail.gmail.com> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <CALx6S34VRS4GumsFSqN8uDkv4TOLC8q+rOvyN=evUk83KPeHHg@mail.gmail.com> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <CALx6S36s_SoTqpPo=jXmrFC+pgUkEmF8UB_sx_0zGcK-G8JeTQ@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <4845d544-7a54-4bba-9f6b-53f67c6e201b@gmail.com>
Date: Fri, 20 Oct 2017 11:38:58 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CALx6S36s_SoTqpPo=jXmrFC+pgUkEmF8UB_sx_0zGcK-G8JeTQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/CE5j_hDeRApcyj5Ts7Fh5FiyTKo>
X-Mailman-Approved-At: Sun, 22 Oct 2017 09:03:33 -0700
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Oct 2017 22:38:57 -0000

Switching to tsvwg. 6man is Bcc'ed. Previous discussions followed on from
https://mailarchive.ietf.org/arch/msg/ipv6/wb339ewBLP7Ijj2eCotCt-W_g8Y

On 20/10/2017 11:00, Tom Herbert wrote:
> On Thu, Oct 19, 2017 at 2:41 PM, Manfredi, Albert E <
> albert.e.manfredi@boeing.com> wrote:
> 
>> -----Original Message-----
>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Toerless Eckert
>>
>>> Finally wrt. architectural cleanlyness: Per-flow service negotiation
>>> IMHO is clearly a transport layer function, there is no concept of
>>> 5-tuple flows at IP layer.
>>
>> I would agree I  principle, although IPv6 does have that flow label that
>> makes the 5-tuple less essential to identify an individual "flow," and it
>> sits at layer 3.
> 
> 
> Right.
> 
> 
>> The problem remains, though: security mechanisms, which render the layer 4
>> QoS knobs unworkable. Everything outside the "security enclaves" at either
>> end, and these security enclaves might just be inside the two end hosts
>> themselves, will have to be delivered best effort.
>>
>> Bert, I don't follow. One of the big wins using the 3-tuple is that it can
> still indicate a flow even if all the transport transport headers and
> payload are encrypted. So this should allow specifying QoS without
> revealing anything about the content except that the sender wants to group
> certain packets together as a flow and apply QoS on them.

Exactly. That's also why the flow label and traffic class are not covered
by IPSec authentication, in case some mechanism changes them en route.

   Brian