Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt

Bob Briscoe <ietf@bobbriscoe.net> Fri, 05 March 2021 10:33 UTC

Return-Path: <ietf@bobbriscoe.net>
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 ADB4D3A2331 for <tsvwg@ietfa.amsl.com>; Fri, 5 Mar 2021 02:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Level:
X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 4gUzOHRm9KVE for <tsvwg@ietfa.amsl.com>; Fri, 5 Mar 2021 02:33:30 -0800 (PST)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (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 EB1503A2330 for <tsvwg@ietf.org>; Fri, 5 Mar 2021 02:33:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bVpyzAp57edUYIQDINXCgdZCFinX6LU64Q622DN96uk=; b=eQC9zBpVpgODmYUZ7ZzAMD/cQz 4+JWnWgEWlghCV2qSx1lSYQ4dKYxGOZyMGOig04oMqQSFKI6exDOkq0xbmzupiWufxeXZPPZxfzRy ND6N1HuAC1b75Agn0bolv/G9ZBWh6NLgLLL3T8cBaCduozzE9Hz27PXpAidBXQOesTFDbMZs1xjqW Rn4M/mVEDsaEs0cqnNk8J/EPD1kxE1FT/+Avt72sIFbVzoDPKKLcbSX/dqy2/uYV0k/x1crc7Z/OR s5sWjaiSjdvoqAqdwb5t1R866MeHGYf3lGj+u377YdFtZs9GSQKSI9TJUH0L56qJ0qIByldaxfk4S zR8FFFuQ==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:54800 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1lI7lw-0004V9-8x; Fri, 05 Mar 2021 10:33:28 +0000
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <161403126355.2878.575062349927307577@ietfa.amsl.com> <20210225200602.lix6lyq2w6c6bclz@debian.debian> <bb46880a-0e4a-b5a3-24a8-95123a3d6a48@bobbriscoe.net> <HE1PR0701MB22993AB48783A4E011335A36C2989@HE1PR0701MB2299.eurprd07.prod.outlook.com> <f618a4b0-eed3-f369-8646-bd6a6c99a2a7@bobbriscoe.net> <HE1PR0701MB22996B90865665EEAEACB8F7C2979@HE1PR0701MB2299.eurprd07.prod.outlook.com> <c2ff0735-6c48-dcd6-d59c-118cff3bfe2d@bobbriscoe.net> <5b46ce90-dd4a-2938-e47e-615af2c3032e@bobbriscoe.net> <HE1PR0701MB22999191DE9B8F34FBA48174C2969@HE1PR0701MB2299.eurprd07.prod.outlook.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <26030574-048c-8dde-55c5-b649052a0358@bobbriscoe.net>
Date: Fri, 05 Mar 2021 10:33:27 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <HE1PR0701MB22999191DE9B8F34FBA48174C2969@HE1PR0701MB2299.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/SJ--D_crFy9kDMHMHXrZRraX150>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt
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: Fri, 05 Mar 2021 10:33:32 -0000

Ingemar, see [BB] inline

On 05/03/2021 09:48, Ingemar Johansson S wrote:
> Hi
>
> Please see inline
>
>> -----Original Message-----
>> From: Bob Briscoe <ietf@bobbriscoe.net>
>> Sent: den 4 mars 2021 19:21
>> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>;
>> tsvwg@ietf.org
>> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt
>>
>> Ingemar,
>>
>> Sorry, you probably thought this thread had ended this morning, but...
>>
>> I've had someone suggest (off list), that the conclusion that RTCP datagrams
>> can be ECN-capable ought to be written (informatively) into ecn-l4s-id. It
>> would go in Appendix A.2.1, which would have to be
>> retitled: "Setting ECT in -TCP- Control Packets and Retransmissions".
>>
>> Before doing that, I checked RFC6679. It says "RTCP reports MUST NOT be
>> ECT marked, since ECT-marked traffic may be dropped if the path is not ECN
>> compliant."
>>
>> This seems rather paranoid, given the path is first checked for ECN support
>> before using it on RTP media. It justifies this by saying the path might change
>> to one that black-holes ECN-capable traffic. Whatever, if RFC6679 (proposed
>> standard) says this, I don't want to contradict it.
>> Do you think it would be OK to say:
>>
>> "RFC6679 precludes the use of ECT on RTCP datagrams, in case the path
>> changes after it has been checked for ECN traversal. L4S experiments will
>> need to observe this rule. Nonetheless, as ECN usage becomes more
>> widespread, it would be useful to gather data on whether such caution is
>> necessary."
> [IJ] Yes. it makes sense. I guess the text was written at a time when it was uncertain how likely ECT traffic is to become black holed. I understand that today these cases are quite rate.
> Still, if it happens, then real time streaming applications should implement circuit brakers  (https://tools.ietf.org/html/rfc8083) . This should make it safe to use ECT for RTCP traffic as well.

[BB] In a 2017 measurement study, we found ECN was wiped on 0.23% of 
paths from residential fixed access vantage points. But with mobile 
access, we found 10.5 / 18 of the EU mobile networks we tested wipe the 
ECN field at the first IP hop incoming to their network (the 0.5 of an 
operator was solely wiping on port 80).
     See https://bobbriscoe.net/pubs.html#measure-generalized-ecn
Some follow-up contacts with the operator found this was probably not 
deliberate wiping; most likely bugs in kit wiping the DS field.

So we're probably not out of the woods yet.


Bob

>
>> Does that seem reasonable?
>>
>>
>> Bob
>>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/