Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-le-phb-09: (with COMMENT)

Roland Bless <roland.bless@kit.edu> Wed, 20 February 2019 22:16 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 A6AD8129AA0; Wed, 20 Feb 2019 14:16:17 -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, 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 aMqOYPjpL94j; Wed, 20 Feb 2019 14:16:14 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::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 9891D128701; Wed, 20 Feb 2019 14:16:14 -0800 (PST)
Received: from [2a00:1398:2:4006:282e:4e48:eadc:38fb] (helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 2a00:1398:2::10:8 id 1gwa9z-0006rD-HB; Wed, 20 Feb 2019 23:16:11 +0100
Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 329AE421031; Wed, 20 Feb 2019 23:16:10 +0100 (CET)
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
Cc: tsvwg@ietf.org, tsvwg-chairs@ietf.org, draft-ietf-tsvwg-le-phb@ietf.org
References: <155043147510.3948.12077924366429728303.idtracker@ietfa.amsl.com>
From: Roland Bless <roland.bless@kit.edu>
Openpgp: preference=signencrypt
Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= mQINBFi0OxABEACy2VohJ7VhSu/xPCt4/6qCrw4Pw2nSklWPfAYEk1QgrbiwgvLAP9WEhAIU w45cojBaDxytIGg8eaYeIKSmsXjHGbV/ZTfo8r11LX8yPYR0WHiMWZpl0SHUd/CZIkv2pChO 88vF/2FKN95HDcp24pwONF4VhxJoSFk6c0mDNf8Em/Glt9BcWX2AAvizTmpQDshaPje18WH3 4++KwPZDd/sJ/hHSXiPg1Gdhs/OG/C0CJguOAlqbgSVAe3qKOr1M4K5M+wVpsk373pXRfxd7 ZAmZ05iBTn+LfgVcz+AfaKKcsWri5CdTT+7JDL6QNQpox+b5FXZFSHnEIST+/qzfG7G2LqqY mml6TYY8XbaNyXZP0QKncfSpRx8uTRWReHUa1YbSuOxXYh6bXpcugD25mlC/Lu0g7tz4ijiK iIwq9+P2H1KfAAfYyYZh6nOoE6ET0TjOjUSa+mA8cqjPWX99kEEgf1Xo+P9fx9QLCLWIY7zc mSM+vjQKgdUFpMSCKcYEKOuwlPuOz8bVECafxaEtJJHjCOK8zowe2eC9OM+G+bmtAO3qYcYZ hQ/PV3sztt/PjgdtnFAYPFLc9189rHRxKsWSOb4xPkRw/YQAI9l15OlUEpsyOehxmAmTsesn tSViCz++PCdeXrQc1BCgl8nDytrxW+n5w1aaE8aL3hn8M0tonQARAQABtChSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+iQJABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEuQINBFi0OxABEAC2CJNp0/Ivkv4KOiXxitsMXZeK9fI0NU2JU1rW 04dMLF63JF8AFiJ6qeSL2mPHoMiL+fG5jlxy050xMdpMKxnhDVdMxwPtMiGxbByfvrXu18/M B7h+E1DHYVRdFFPaL2jiw+Bvn6wTT31MiuG9Wh0WAhoW8jY8IXxKQrUn7QUOKsWhzNlvVpOo SjMiW4WXksUA0EQVbmlskS/MnFOgCr8q/FqwC81KPy+VLHPB9K/B65uQdpaw78fjAgQVQqpx H7gUF1EYpdZWyojN+V8HtLJx+9yWAZjSFO593OF3/r0nDHEycuOjhefCrqr0DDgTYUNthOdU KO2CzT7MtweRtAf0n27zbwoYvkTviIbR+1lV1vNkxaUtZ6e1rtOxvonRM1O3ddFIzRp/Qufu HfPe0YqhEsrBIGW1aE/pZW8khNQlB6qt20snL9cFDrnB6+8kDG3e//OjK1ICQj9Y/yyrJVaX KfPbdHhLpsgh8TMDPoH+XXQlDJljMD0++/o7ckO3Sfa8Zsyh1WabyKQDYXDmDgi9lCoaQ7Lf uLUpoMvJV+EWo0jE4RW/wBGQbLJp5usy5i0fhBKuDwsKdLG3qOCf4depIcNuja6ZmZHRT+3R FFjvZ/dAhrCWpRTxZANlWlLZz6htToJulAZQJD6lcpVr7EVgDX/y4cNwKF79egWXPDPOvQAR AQABiQIlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/jNeiglj8fenH2We 7SJuyBp8+5L3n8eNwfwY5C5G+etD0E6/lkt/Jj9UddTazxeB154rVFXRzmcN3+hGCOZgGAyV 1N7d8xM6dBqRtHmRMPu5fUxfSqrM9pmqAw2gmzAe0eztVvaM+x5x5xID2WZOiOq8dx9KOKrp Zorekjs3GEA3V1wlZ7Nksx/o8KZ04hLeKcR1r06zEDLN/yA+Fz8IPa0KqpuhrL010bQDgAhe 9o5TA0/cMJpxpLqHhX2As+5cQAhKDDsWJu3oBzZRkN7Hh/HTpWurmTQRRniLGSeiL0zdtilX fowyxGXH6QWi3MZYmpOq+etr7o4EGGbm2inxpVbM+NYmaJs+MAi/z5bsO/rABwdM5ysm8hwb CGt+1oEMORyMcUk/uRjclgTZM1NhGoXm1Un67+Rehu04i7DA6b8dd1H8AFgZSO2H4IKi+5yA Ldmo+ftCJS83Nf6Wi6hJnKG9aWQjKL+qmZqBEct/D2uRJGWAERU5+D0RwNV/i9lQFCYNjG9X Tew0BPYYnBtHFlz9rJTqGhDu4ubulSkbxAK3TIk8XzKdMvef3tV/7mJCmcaVbJ2YoNUtkdKJ goOigJTMBXMRu4Ibyq1Ei+d90lxhojKKlf9yguzpxk5KYFGUizp0dtvdNuXRBtYrwzykS6vB zTlLqHZ0pvGjNfTSvuuN
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
Message-ID: <9451008a-9076-a112-9c83-5818e00a4c36@kit.edu>
Date: Wed, 20 Feb 2019 23:16:10 +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: <155043147510.3948.12077924366429728303.idtracker@ietfa.amsl.com>
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 esmtpsa 1550700971.617025069
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/cfS4F69rpyblx8-1M245wxfWDr0>
Subject: Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-le-phb-09: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Feb 2019 22:16:18 -0000

Hi Benjamin,

On 17.02.19 at 20:24 Benjamin Kaduk wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This document is generally in fine shape, and has some good discussion
> in it.  I basically just have some editorial suggestions.
> 
> As one general note, the text sometimes seems to present a mixed story,
> for example in the case of "downgrading" traffic from other PHBs.  We're
> told to in general not do this instead of dropping traffic, but on the
> other hand an example use of the LE PHB is for downgrading traffic from
> some other PHB (but only when it does not violate the operational
> objectives of that other PHB).  Greater clarity on who is authorized to
> decide to downgrade, and in what cases it makes sense, could be useful.

Ok, I'll re-read the text and try to add a bit of clarifying text.

> In a similar vein, the text sometimes suggests a dichotomy between use
> of the LE PHB for "preemptable" traffic vs. as a "scavenger" service
> class, and at other times suggests that these usages are identical.  But
> those are, of course, editorial matters.

Thanks for pointing that out. I think you are right, but it
is the very nature of the LE: it should scavenge residual capacity,
but it must be preemptable by BE in case it needs more resources,
so it has both facets.


> Abstract
> 
>                                         The primary objective of this LE
>    PHB is to protect best-effort (BE) traffic (packets forwarded with
>    the default PHB) from LE traffic in congestion situations, i.e., when
>    resources become scarce, best-effort traffic has precedence over LE
>    traffic and may preempt it.  Alternatively, packets forwarded by the
>    LE PHB can be associated with a scavenger service class, i.e., they
>    scavenge otherwise unused resources only.  [...]
> 
> It seems like "preemptable" and "scavenger" are being deliberately
> conflated, but are not necessarily the same.

The scavenger part came in somewhat late and that may have caused
the confusion by the conflation. I'll try to clarify this a bit more.

> Section 3
> 
>    (e.g., if a transport connection fails due to timing out, the
>    application may try several times to re-establish the transport
>    connection in order to resume the application session before finally
> 
> There was some directorate review traffic suggesting that further
> qualifications about the retries; I do see such qualifying statemnets in
> the next paragraph, so maybe there is no big need to do so here as well..

Yep.

>    Use of the LE PHB might assist a network operator in moving certain
>    kinds of traffic or users to off-peak times.  Alternatively, or in
>    addition, packets can be designated for the LE PHB when the goal is
>    to protect all other packet traffic from competition with the LE
> 
> Is it "alternatively" or "in addition" -- can it really be both at the
> same time?  (I suppose the intent is that different operators could
> apply different policies?)

This formulation is actually taken unchanged from the original RFC 3662,
but I may rephrase it. I think it can be "in addition", because
it may belong to different traffic aggregates. The background of this
stems IMHO from the fact that in former times, some operators throttled
or blocked peer-to-peer file sharing traffic. A better option would be
to let users mark it as LE and simply accept it, because it does no
harm to other traffic.

> Section 9
> 
> Is there a section reference in RFC 3754 to point us to?

I don't think so, because the whole RFC discusses Multicast and Diffserv.

> (Also, the RFC Editor will probably put a comma after "Basically".)

Done. :-)

>    Several forwarding error correction coding schemes such as fountain
>    codes (e.g., [RFC5053]) allow reliable data delivery even in
> 
> I'm used to seeing "forward error correction"; is "forwarding error
> correction" also an acceptabale usage?

Good catch, will use Forward Error Correction.

>    While the resource contention problem caused by multicast packet
>    replication is also true for other Diffserv PHBs, LE forwarding is
>    special, because often it is assumed that LE packets get only
> 
> nit: s/get only/only get/

Done.

>    forwarded in case of available resources at the output ports.  The
>    previously mentioned redundancy data traffic could nicely use the
>    varying available residual bandwidth being utilized the by LE PHB,
>    but only if the previously specific requirements in the internal
>    implementation of the network devices are considered.
> 
> I'm not sure how to interpret "previously specific requirements", here.
> Was it intended to be "previously specified requirements"?

Ok, then I need to state that more explicitly: it refers to the
replication condition in the preceding paragraph.

> Section 12
> 
> As per the GenART review, updating the draft in missref is a bit weird,
> but we can probably leave it to the responsible AD and RFC Editor to
> decide whether to retain the "Updates" relationship or directly effect
> the needed changes.

Spencer already replied to this.

Best regards,
 Roland