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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 10 February 2019 03:29 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 52C82128CB7; Sat, 9 Feb 2019 19:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 lJPgYWXkdBMa; Sat, 9 Feb 2019 19:29:09 -0800 (PST)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 917A112894E; Sat, 9 Feb 2019 19:29:09 -0800 (PST)
Received: by mail-pf1-x434.google.com with SMTP id z9so3593577pfi.2; Sat, 09 Feb 2019 19:29:09 -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=e3Ce6dugKaSDu7g2vzTzG7RYaiE9/RbyGtTQehD9+1g=; b=IVtGVsFSiSM8UZJ3zJ0A2M7rpHAAMvY2VghtRxp6wJCj4CSwSOqUe4JmkiaAiaoQqO juW0LydYpg2OWOaQAluKagG72au6jAzFHZ+HuSeKgo6q4GyR815HVySfNnslBavfmNVL 8pG1NotdBDWbpyklRcz4lFOE3ank3ATOnXpm6kiBtk4OiO2FIOZtdBy2/MGbn3f3Kk6s hMczfbhksMOuF+4Ycozway13edfHPWQJXQqZPNgQoOpPSvihV/2cSxlKN4ScXc4IzGb4 UFV3h2shbYLSNCFpX+BCtSRWUB4gSzuyqiA1kWUbYEiOjSw1OC4ZDe4SifVXPWDo7jmF GXbg==
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=e3Ce6dugKaSDu7g2vzTzG7RYaiE9/RbyGtTQehD9+1g=; b=V9yCg3XxdarB8oEkYYzD8gL6E3HICzvVqmh7RyVo1w62osjmVI+FqiDkRUqxEgoIkA NOBKaB3F9minAn0CvFQhE9H/zksXVUIl0WFkUgEdu1SwbpK3B6F+xuqVxwO1txK6wReb lFKbn7B1ri9jIPvpbmEMW3myb9EhnyAvzWNwz0bhEGyPm6BJ6UO2dQwHYif4QIPcWKZE WLQvKrjdBWn1e71qggP0W2ofPTDkurQo0hyDowih/sqqz29WbqOMoV3tSIvAYpk254Go li5tcXkirQi33XNER5j9GXcFKXZDMI7cJWLbWqrqGSdIVrGdL5lFW2smFOg7vD7cOdfs tKjg==
X-Gm-Message-State: AHQUAuYXYLgn0OC1HCkH2V+OpAe/8LYcvRNLFSlmon93Mz9q8bfKblZ3 B05fgfn4CyIqlOanGMjgm99bmLtb
X-Google-Smtp-Source: AHgI3Ibx1TqavCL6Rt+VzEs1ukt+seNXND+xtV6L/TTJFyanV+jZ+QC/4QMSMq8Tw8IfOlY26jLXJQ==
X-Received: by 2002:a63:d347:: with SMTP id u7mr11947304pgi.383.1549769348386; Sat, 09 Feb 2019 19:29:08 -0800 (PST)
Received: from [192.168.178.30] ([118.148.79.176]) by smtp.gmail.com with ESMTPSA id k71sm10828403pga.44.2019.02.09.19.29.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 19:29:07 -0800 (PST)
To: Christian Huitema <huitema@huitema.net>, 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> <f6e9c30c-7d85-b8df-9cd9-1f68c7eed45a@gmail.com> <0f5c3c25-4314-7e5e-1b1e-0778e292e370@huitema.net>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <1907e345-65d6-6231-1b2e-4fbb3aaea6e2@gmail.com>
Date: Sun, 10 Feb 2019 16:29:01 +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: <0f5c3c25-4314-7e5e-1b1e-0778e292e370@huitema.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ody_NVx7gs5aB9DHgsYEEe3kx_0>
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: Sun, 10 Feb 2019 03:29:11 -0000

On 2019-02-10 13:33, Christian Huitema wrote:
> 
> On 2/9/2019 10:52 AM, Brian E Carpenter wrote:
>>> 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.
> 
> There is some experience of that with other scavenger modes, e.g. using LEDBAT. Slowing down to a trickle is fine, but slowing down to zero is not. In practice, many applications that are willing to use a scavenger mode will trigger an error if they see no progress for a sustained amount of time, and then they will restart the connection and remove the LEDBAT or LE option -- which of course defeats the purpose.

Well, that's not a true scavenger application. Restarting the transport connection
might be a reasonable option, but giving up on LE is effectively saying "lower
effort is not really what I wanted."

Anyway, I think that reinforces my point: it's an interesting discussion, but
out of scope for this draft.

    Brian