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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 09 February 2019 20:52 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 DDC2B130F1A; Sat, 9 Feb 2019 12:52:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 37bO2QKFpygL; Sat, 9 Feb 2019 12:52:30 -0800 (PST)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 5EBB2130ED1; Sat, 9 Feb 2019 12:52:30 -0800 (PST)
Received: by mail-pg1-x530.google.com with SMTP id r11so3108020pgp.6; Sat, 09 Feb 2019 12:52:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1Rfrpv7FcLz1rAla+CECYrGNIwnYDXjuim50BTHCmeg=; b=ovk+M/Y1snABEhCcZDN49i54/cB+REzc/j4Y+IVMHdYJZHL/5Aktq7FYVrxfYEZW7q r8XRp10zHJ1AVl567iGOhKYL6b3meJ89MRYwC2TmIJWoIjPH4D5bzsl2jl46JRo0mQDr RU1BLqW8xCXjQn1F9SZMw4tyNMWkQZJcEwB6SMWJAKQCma6t2C/cMsCvDhkUDJBnV6NH Cs66GwUQ+Dzhkj5pOCyBIx2KL/Wss9HRm/34GWZZFXDOMvfqMB1KOTftjriHigmkVZZj qfK9EkBBGEzwUAEnQlpY/9JzJoe1IXdqSPtPjHKHFrBmCs+S9nbqONEsJ9TPThk5voRJ MiZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1Rfrpv7FcLz1rAla+CECYrGNIwnYDXjuim50BTHCmeg=; b=STLCF6YcEl24xUzIUU8I5cqQNGnBhndORsfV3e8A/uAb1RNjZ2t7y3U4F1IsmJi/9T Ras03XeaCXW9Tj/86bZ2M2KmHzu/MlthDv1kXQqEnlbB56wrMKv7lOG+Bs5j+T1GyRFt wkZ0ak62AonCf4fYrdRWIB+N7hXZjWine6nUBO5fgRiOg/PysifGUbcwq8fWaTmK8Jnk BGx4l8hyhVFfgGHHNDNPORNPKhhdUHXBPprjqv9dc9WiIIL+PCgqF8qL4w69c2b7Zbfe yyvV+raChsFfRztdNGWMHhPfRWOqvTCniuvB0OfF4g4xCJD8sykQGTyuywsJ471yzV8o tq6g==
X-Gm-Message-State: AHQUAubMf1H1bW51dmE0KzRc8JptBdhqZxDgeHKe+bdupLdsZPoD8Fyf LO6oqLVjqeR4MXilU/dZSyoAelKD
X-Google-Smtp-Source: AHgI3IbI6g5qb28mLaBfgjSdrS1MN8lWDiA4A9x1Eqap+UnQ2tLmGJxZSco2rQZPcSU1I/bYMlLS+Q==
X-Received: by 2002:a62:444b:: with SMTP id r72mr29571977pfa.184.1549745548945; Sat, 09 Feb 2019 12:52:28 -0800 (PST)
Received: from [192.168.178.30] ([118.148.79.176]) by smtp.gmail.com with ESMTPSA id i71sm4435072pfi.170.2019.02.09.12.52.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 12:52:27 -0800 (PST)
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: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <f6e9c30c-7d85-b8df-9cd9-1f68c7eed45a@gmail.com>
Date: Sun, 10 Feb 2019 09:52:23 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <154971079073.29335.8312320805145229104@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bQGitanqSRrJcf0QPs8uLdJ7cBw>
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: Sat, 09 Feb 2019 20:52:33 -0000

Hi Olivier,
On 2019-02-10 00:13, Olivier Bonaventure wrote:
> Reviewer: Olivier Bonaventure
> Review result: Ready with Nits
> 
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
> 
> The document proposes lower than best effort service and discusses its
> implementation using Diffserv techniques. It is generally in good shape, but
> there are two parts which could be clarified from a transport viewpoint.
> 
> 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.

Isn't that what the SHOULD already says? There's no implication that
one would use TCP. I would expect a pragmatic UDP-based mechanism. But
I don't think this draft should cover that - its role is to define the
code point and the per-hop behaviour, not the end to end protocol.

> 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.
> 
> 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.

Yes and no. Suppose that the LE class is starved on a particular path except
between 2 a.m. and 4 a.m. every morning. A naive exponential backoff would
start at 4 a.m. on Monday and by 2 a.m. on Tuesday it could have reached
a timeout of more than 2 hours. To make prompt use of the bandwidth at 2 a.m.,
it would instead need to be retrying every minute or two.

Again - we shouldn't say too much about this in the PHB definition.
 
> 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 ?

Same comment - a good question, maybe a good M.Sc. topic, but not part of
the PHB definition.
 
> 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 agree, although LE only makes an existing problem worse. There does seem
to be some literature on FEC+diffserv+multicast, e.g. https://doi.org/10.1109/ICECS.2003.1301723

Regards
     Brian