Re: [AVTCORE] RFC6679 ECN in RTP: intent of ect = 0, 1, or random?

Bob Briscoe <> Thu, 05 November 2015 10:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E1A551A92E4 for <>; Thu, 5 Nov 2015 02:05:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RIC6n1bmTLCq for <>; Thu, 5 Nov 2015 02:05:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B9C81A92E5 for <>; Thu, 5 Nov 2015 02:05:02 -0800 (PST)
Received: from ([]:43740) by with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from <>) id 1ZuHPg-0007oW-EC; Thu, 05 Nov 2015 10:05:01 +0000
To: Colin Perkins <>
References: <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Thu, 5 Nov 2015 10:04:55 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
X-Mailman-Approved-At: Fri, 06 Nov 2015 06:26:52 -0800
Cc: Ingemar Johansson S <>, Magnus Westerlund <>, Ken Carlberg <>,
Subject: Re: [AVTCORE] RFC6679 ECN in RTP: intent of ect = 0, 1, or random?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Nov 2015 10:05:12 -0000


OK. In the fullness of time, if our proposal continues to get traction, 
I'll draft a little experimental bis to ECN in RTP to specify scalable 
congestion control. It will be v simple:

If using scalable cc:
* sender only uses scalable cc if (all) receiver(s) report ECN support
* sender rate equation is like TFRC equation, but with 1/p instead of 
* fall back to TFRC equation on loss rather than ECN (and also possibly 
on ECN accompanied by high variable delay) for 'a few' 1RTT (TBD)
* sender sets ECT(1) not ECT(0)
* no changes on receiver
* I think it would work deployed one RTP hop at a time, but that would 
have to be tested

But I'd want to implement and test it first, of course.


On 05/11/15 07:34, Colin Perkins wrote:
> Bob,
>> On 4 Nov 2015, at 17:50, Bob Briscoe <> wrote:
>> Piers,
>> I realised I didn't send the mail thanking you for your response. Thank you - v useful, and confirmation of my vague memory of events.
>> 1. Would the authors (and wider community) be happy to allow ECT(1) not to be set-aside for future anti-cheating use, as long as there was another way, in principle, for the sender to check for cheating?
> I have no objection. You might check with the RMCAT chairs, since some of their proposals make use of ECN with RTP, but I doubt this will be a problem.
>> For TCP, we worked out a way for the sender to check for cheating without burning a codepoint - by the sender introducing one or two CE codepoints of its own, and checking the receiver reports them. Would this be harder for RTP? Are the receiver reports deterministic enough for the sender to determine whether codepoints it injected are correctly counted in the next report?
> The sender could easily set a CE mark on a small number of packets it’s sending. For unicast cases, where there’s an explicit control loop, it should be able to correlate this with the returned RTCP feedback. Where it might be difficult is with open loop layered multicast congestion control, where some receivers might see the CE mark and drop a layer since they don’t know it’s a synthetic mark.
> Colin
>> 2. A couple of days after I posted the original question, we posted the -00 individual draft aiming to start the process of repurposing ECT(1). You will see the sentence in the scope section <>
>> See security considerations for discussion on feedback integrity checking.
>> Bob
>> On 19/10/15 10:15, Piers O'Hanlon wrote:
>>> Hi Bob,
>>> I think the reasoning was that ECT(1)/random could potentially be used to detect cheating/failures as mentioned in section 7.4, but I can't see that it's going to make a lot of difference if ECT(1) is not used.
>>> Piers
>>> On 17 Oct 2015, at 22:59, Bob Briscoe wrote:
>>>> Guys,
>>>> [Ignore last identical email - I left the list off the distr in error]
>>>> I'm writing a draft to propose a new use for ECT(1).
>>>> In reading RFC6679, It says that the there is no intent to use an ECN nonce.
>>>> Also it says the receiver might want to advise the sender not to use ect=random, if its behind a header compression link. And that ect=0 is recommended and the default.
>>>> But it doesn't seem to actually say why a sender might send ECT(1) instead of ECT(0). Or why a sender might use the two randomly. Or why a receiver might ask for ect=1, or ect=random.
>>>> I'm trying to work out whether there would be any detriment to RFC6679 if it couldn't use ECT(1). It looks like not.
>>>> Bob
>>>> -- 
>>>> ________________________________________________________________
>>>> Bob Briscoe
>> -- 
>> ________________________________________________________________
>> Bob Briscoe

Bob Briscoe