[tsvwg] Remarking of LE (draft-ietf-tsvwg-le-phb-02)

"Bless, Roland (TM)" <roland.bless@kit.edu> Wed, 12 July 2017 12:46 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 1B3C512EC30 for <tsvwg@ietfa.amsl.com>; Wed, 12 Jul 2017 05:46:35 -0700 (PDT)
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 l2DOPMh8zSDm for <tsvwg@ietfa.amsl.com>; Wed, 12 Jul 2017 05:46:32 -0700 (PDT)
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 0B4C612426E for <tsvwg@ietf.org>; Wed, 12 Jul 2017 05:46:32 -0700 (PDT)
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 1dVH2E-0006CY-3E for <tsvwg@ietf.org>; Wed, 12 Jul 2017 14:46:30 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 09E8FB007C8 for <tsvwg@ietf.org>; Wed, 12 Jul 2017 14:46:30 +0200 (CEST)
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <c15e729a-e1c6-b96e-b570-168e70d04d82@kit.edu>
Date: Wed, 12 Jul 2017 14:46:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
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 1499863590.160193096
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/p51n02f0Gv9snh_recpT1cpl8qw>
Subject: [tsvwg] Remarking of LE (draft-ietf-tsvwg-le-phb-02)
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: Wed, 12 Jul 2017 12:46:35 -0000

Hi,

In https://mailarchive.ietf.org/arch/msg/tsvwg/d70Z9JoLOWtQCadD_uA9pJ9tBx4
David made the comment:
> ****I definitely want to see broader WG discussion of that “MUST remark” requirement, as it’s not backwards compatible with RFC 4594 - at a minimum, some thought should be applied to transition and mixing networks that use CS1 and the new LE DSCP.

Here are some general thoughts on remarking of the LE PHB.

If correctly implemented LE (lower effort) traffic will not harm BE
(best-effort) traffic, because BE traffic will preempt LE traffic.
DiffServ Domains that are not implementing LE may carry LE traffic
within their BE aggregate. They must be aware, however, that the
"no harm" property of LE is not given.

There are now two types of LE users:
LE-min: this user does not care if LE packet experience better
forwarding treatment, so promoting them to BE is ok.

LE-strict: this user wants to be sure that LE is obeying the
"no harm" property, i.e., only otherwise unused resources
should be consumed by LE traffic.

The question is now, how the LE-strict user can detect whether
the packets were promoted to BE. Let's assume we have two
different DSCPs LE-min and LE-strict. Then:
LE-min: can be promoted to BE, but should stay marked as LE-min
        to let subsequent domains handle it correctly as LE traffic
LE-strict: should not be promoted to BE. Now we have two cases:
           a) DS domain remarks to BE and passes it as BE to the next DS
              domain. The receiver could probably use some feedback
              channel to let the sender know that this remarking
              happened.
              An appropriate reaction should be left to the application
              then (continue, abort, use LE transport protocol,
              rate limit, etc.) => E2E principle.
           b) DS domain simply drops the LE packet.

I think b) is not useful.

Coming back to the question above:
A DS domain must be able to map DSCP to PHB freely (see RFC 2474).
So if a DS domain currently supports LE and uses the CS1 DSCP for that,
it should support the new LE DSCP, too.
The current draft says
   A DS domain that still uses DSCP CS1 for marking LE traffic
   (including Low Priority-Data as defined in [RFC4594] or the old
   definition in [RFC3662]) MUST remark traffic to the LE DSCP '000010'
   at the egress to the next DS domain.  This increases the probability
   that the DSCP is preserved end-to-end, whereas a CS1 marked packet
   may be remarked by the default DSCP if the next domain is applying
   DiffServ-intercon [RFC8100].

So a useful strategy would be to always remark CS1 to LE, when
CS1 was used for RFC3662/LE to get rid of the ambiguity of CS1.
More input welcome.

Regards,
 Roland