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

Bob Briscoe <ietf@bobbriscoe.net> Wed, 04 November 2015 08:50 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60841AC3F3 for <avt@ietfa.amsl.com>; Wed, 4 Nov 2015 00:50:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuZ6od5Uhzk4 for <avt@ietfa.amsl.com>; Wed, 4 Nov 2015 00:50:45 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 7C7831AC3DE for <avt@ietf.org>; Wed, 4 Nov 2015 00:50:45 -0800 (PST)
Received: from dhcp-25-140.meeting.ietf94.jp ([133.93.25.140]:51133) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from <ietf@bobbriscoe.net>) id 1ZttmF-0002Qb-1S; Wed, 04 Nov 2015 08:50:43 +0000
From: Bob Briscoe <ietf@bobbriscoe.net>
To: Piers O'Hanlon <p.ohanlon@gmail.com>
References: <f66a871f-ca21-43e2-b363-32f0fe837642@HUB02.ad.oak.ox.ac.uk> <0EA95BA1-4839-41FB-BC9E-33EFB3DB7981@gmail.com>
Message-ID: <5639C6DE.9080606@bobbriscoe.net>
Date: Wed, 04 Nov 2015 08:50:38 +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: <0EA95BA1-4839-41FB-BC9E-33EFB3DB7981@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/UtX_q7FTYAbEQIrJXOcPVudDRbM>
X-Mailman-Approved-At: Wed, 04 Nov 2015 12:39:20 -0800
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "WESTERLUND, Magnus" <magnus.westerlund@ericsson.com>, Colin Perkins <csp@csperkins.org>, Ken Carlberg <carlberg@g11.org.uk>, avt@ietf.org
Subject: Re: [AVTCORE] RFC6679 ECN in RTP: intent of ect = 0, 1, or random?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2015 08:50:48 -0000

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?

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?

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 
<https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-00#section-1.3>

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 Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/