Re: [tsvwg] Tsvart last call review of draft-ietf-tsvwg-le-phb-08

"Bless, Roland (TM)" <roland.bless@kit.edu> Tue, 12 February 2019 10:21 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 68C8A12D861; Tue, 12 Feb 2019 02:21:03 -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 B2dOVjD1MOUX; Tue, 12 Feb 2019 02:21:01 -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 D40C1128CE4; Tue, 12 Feb 2019 02:21:00 -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 esmtpsa port 25 iface 141.3.10.8 id 1gtVBP-0007up-SN; Tue, 12 Feb 2019 11:20:55 +0100
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id C2F294203AE; Tue, 12 Feb 2019 11:20:55 +0100 (CET)
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>, tsv-art@ietf.org
Cc: ietf@ietf.org, draft-ietf-tsvwg-le-phb.all@ietf.org, tsvwg@ietf.org
References: <154971079073.29335.8312320805145229104@ietfa.amsl.com>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Openpgp: preference=signencrypt
Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= xsFNBFi0OxABEACy2VohJ7VhSu/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+n5w1aaE8aL3hn8M0tonQARAQABzShSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+wsGABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEzsFNBFi0OxABEAC2CJNp0/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 AQABwsFlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/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
Message-ID: <297efea4-ffa9-c4c7-95ec-4ff8368f87f2@kit.edu>
Date: Tue, 12 Feb 2019 11:20:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <154971079073.29335.8312320805145229104@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 1549966855.946059353
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bKnGBw-Wud4cCh8j2cfohoZ7Vsw>
Subject: Re: [tsvwg] Tsvart last call review of draft-ietf-tsvwg-le-phb-08
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: Tue, 12 Feb 2019 10:21:03 -0000

Hi Olivier,

Am 09.02.19 um 12:13 schrieb Olivier Bonaventure:
> Reviewer: Olivier Bonaventure
> Review result: Ready with Nits

thanks for the review. See comments inline.

> First, Section 3 mentions : "Since
>    LE traffic could be starved completely for a longer period of time,
>    transport protocols or applications (and their related congestion
>    control mechanisms) SHOULD be able to detect and react to such a
>    starvation situation. "
> 
> This is an important point for such a service. Applications and/or transport
> protocols that are intended to be used with this service should be capable of
> supporting long losses of connectivity that may cause connections to fail. The
> document should strongly recommend to only use this service with
> applications/protocols that are capable of resuming an aborted data transfert.
> A regular TCP connection is usually not capable of doing this and thus using
> the service correctly requires more than simply tagging the packets sent by a
> given TCP connection with the chose DSCP.

That is correct. That's why it's stated in the draft. So one
can use TCP and hope that it works well enough with the available
residual bandwidth, but the application should be prepared to
react on a connection timeout and initiate a new TCP connection
with an application level session resumption. In other cases
one can probably use a transport protocol that is specifically
designed to deal with this kind of starvation periods. However,
that is the worst case and I would expect that there is always
some residual bandwidth for LE available. I think that it is
application dependent, whether long starvation is acceptable or a
connection timeout should indicate a failure (taking Christian
Huitema's comments into account).

> Later, the document states "   While it is desirable to achieve a quick
> resumption of the transfer
>    as soon as resources become available again, it may be difficult to
>    achieve this in practice. "
> 
> I'm not personally convinced that a quick resumption of the transfer is the
> best approach to deal with periods where no LE packet is forwarded by the
> network. If a connection using LE fails, it does not seem to be appropriate to
> try to resume it immediately. It is likely that an approach like exponential
> backoff could make sense to avoid trying to restart such connections too early.

You are right. I had something like an exponential backoff in mind, but
probably with some kind of upper bound (retry every minute or two).
This statement came in by a comment from Spencer who referred to the
trigtran experience. I can add a bit more text on this.
But as Brian Carpenter already mentioned:
this is a PHB specification and transport protocol issues are related
but would be a different focus.

> Second, there is a small discussion of ECN in section 4: "   Since congestion
> control is also useful within the LE traffic class,
>    Explicit Congestion Notification [RFC3168] SHOULD be used for LE
>    packets, too."
> 
> Does this imply that LE packets SHOULD also be ECT capable packets, i.e. when a
> transport protocol is used to provide LE service, it should also support ECN or
> is this requirement weaker ?

Again, since this is a PHB specification, the focus is on forwarding.
For ECN you need both: the ECN capable transport protocol and the ECN
marking in the queue. So the recommendation is to use an ECN capable
transport (that would use ECT) for LE and to have ECN capable marking
for the LE queue. The recommendation was targeted a bit at the latter:
if the node is able to set the CE bit, then it only depends on the
transport to use ECN (which is also recommended). I'm not sure that this
should be stated more explicitly.

> Finally, Section 9 discusses the Multicast considerations. It mentions the
> utilisation of forward error correction schemes. One risk with FEC combined
> with LE is that FEC increases the amount of data that needs to be transferred
> and thus consumes ressources in non-congested parts of the network for packets
> that will be discarded downstream during periods of congestion. If there are
> simulation or measurement results that demonstrate that combining FEC and LE
> provides good results, it would be interesting to cite those results.

I think the idea was to use LE for the redundancy data only as the last
sentence points out:
"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.
So the normal data stream uses BE, while the FEC data uses LE.
The multicast considerations were suggested by Toerless Eckert. Maybe he
can provide some pointers if there are some.

best regards
 Roland