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

Brian E Carpenter <> Sun, 10 February 2019 03:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52C82128CB7; Sat, 9 Feb 2019 19:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lJPgYWXkdBMa; Sat, 9 Feb 2019 19:29:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 917A112894E; Sat, 9 Feb 2019 19:29:09 -0800 (PST)
Received: by with SMTP id z9so3593577pfi.2; Sat, 09 Feb 2019 19:29:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 [] ([]) by with ESMTPSA id k71sm10828403pga.44.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 19:29:07 -0800 (PST)
To: Christian Huitema <>, Olivier Bonaventure <>,
References: <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [tsvwg] Tsvart last call review of draft-ietf-tsvwg-le-phb-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.