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
- [tsvwg] Tsvart last call review of draft-ietf-tsv… Olivier Bonaventure
- Re: [tsvwg] Tsvart last call review of draft-ietf… Dave Taht
- Re: [tsvwg] Tsvart last call review of draft-ietf… Brian E Carpenter
- Re: [tsvwg] Tsvart last call review of draft-ietf… Christian Huitema
- Re: [tsvwg] Tsvart last call review of draft-ietf… Brian E Carpenter
- Re: [tsvwg] Tsvart last call review of draft-ietf… Christian Huitema
- Re: [tsvwg] Tsvart last call review of draft-ietf… Christian Huitema
- Re: [tsvwg] Tsvart last call review of draft-ietf… Bless, Roland (TM)