Re: [tsvwg] Planned update of draft-ietf-tsvwg-le-phb

Roland Bless <roland.bless@kit.edu> Tue, 21 November 2017 18:33 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531CD129B97 for <tsvwg@ietfa.amsl.com>; Tue, 21 Nov 2017 10:33:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 vi3pX3LJjm5V for <tsvwg@ietfa.amsl.com>; Tue, 21 Nov 2017 10:33:37 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 33EC6129AC1 for <tsvwg@ietf.org>; Tue, 21 Nov 2017 10:33:35 -0800 (PST)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1eHDMS-0000nn-0N; Tue, 21 Nov 2017 19:33:32 +0100
Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id AAE22B00741; Tue, 21 Nov 2017 19:33:31 +0100 (CET)
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, tsvwg <tsvwg@ietf.org>
References: <f6846a8c-71fe-c7c6-86b8-e27d7b6a7c12@kit.edu> <8263E3A1-F304-4C64-89B2-031779FB4FC1@trammell.ch>
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
Message-ID: <25457fc7-2e2a-9d4d-cc85-a874bc3a69e1@kit.edu>
Date: Tue, 21 Nov 2017 19:33:31 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
In-Reply-To: <8263E3A1-F304-4C64-89B2-031779FB4FC1@trammell.ch>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1511289212.075210832
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/IKtPEiv27wWzlkY90fXBmL6tw0c>
Subject: Re: [tsvwg] Planned update of draft-ietf-tsvwg-le-phb
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 18:33:40 -0000

Hi Brian,

On 21.11.2017 at 14:38 Brian Trammell (IETF) wrote:
>> On 17 Nov 2017, at 04:04, Roland Bless <roland.bless@kit.edu> wrote:
>>
>> Hi,
>>
>> as just stated in the session, I plan to update draft-ietf-tsvwg-le-phb
>> to version 3 with at least the following changes:
>>
>> - Update the DSCP recommendation to pick a DSCP from Pool 3 (XXXX01),
>>  either 1 or 5 (technical feedback on that appreciated).
> 
> For what it's worth, a student of ours, Michael Walter, is running some measurements on this just now. I'm waiting for a more detailed report from him, but in preliminary results using a Tracebox-like methodology on ~200k paths from a DigitalOcean node show that packets marked DSCP 46 are rewritten to DSCP 1 on about 300 paths, and to DSCP 5 on about 700 paths. So DSCP 1 seems preferable to DSCP 5 on a "not used in the Internet" sense, but both seem to be used on O(1e-3) paths.

Thanks for investigating this. DSCP 46 is EF and DSCP 1 and 5 are
local-use right now. So this is IMHO a weird behavior. Given the
small percentage, I don't see real problems here.

Regards,
 Roland


>> - Update to RFCXXXX (right now draft-ietf-tsvwg-ieee-802-11):
>>  put in a section (similar to section 6) that describes
>>  changes to that RFC. To be clear here:
>>  draft-ietf-tsvwg-ieee-802-11 should not be updated, it should
>>  proceed to RFC as is. draft-ietf-tsvwg-le-phb, however, would
>>  add changes to that RFC, e.g.,
>>   +---------------+------+---------+-------------+--------------------+
>>   | Low-Priority  | LE   | RFC(LE) |     1       | AC_BK (Background) |
>>   |     Data      |      |         |             |                    |
>>   +-------------------------------------------------------------------+
>>  It is, however, not clear to me whether to replace the existing
>>  mapping or to add it.
>> - remove the LE-min, LE-strict discussion as it seems to be ok
>>  recommending a LE transport (e.g., LEDBAT++) on top if one wants
>>  LE-strict semantics.
>>
>> Regards,
>> Roland
>>
>