IETF Logo Mail Archive

RE: Adding ECN to Transport and Recovery

"Lubashev, Igor" <ilubashe@akamai.com> Mon, 11 June 2018 12:23 UTC

Return-Path: <ilubashe@akamai.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16ABB130E37 for <quic@ietfa.amsl.com>; Mon, 11 Jun 2018 05:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 XrN98kd9TKT9 for <quic@ietfa.amsl.com>; Mon, 11 Jun 2018 05:23:47 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 1F9F0130E30 for <quic@ietf.org>; Mon, 11 Jun 2018 05:23:47 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5BCIE7j032078; Mon, 11 Jun 2018 13:23:32 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=QRM1yxbhd5m4TREOkmo4eVSmOIFm8ci+4OLi0/HbFmo=; b=DfrPp/4DPqsyt5Vic3vqNSDaJcCtv3tzOVwrwGQRGy6qRm4hmsjuF4kxE7qw5yNC/qjY lHxoNV0KW1EzKfDes/oZudiZ7aOvVEpyU/3htCl3JVw5gpbJWPWZni3zfxrUz8WRlUZZ SShjcjr1VzILiY8vjRvvudh1fTDwJks3y67kgXSboSketsbMpiIkKTPEAz5ZpYPr5B4Y NkT7e0XTKUjKNrjBV03eRmA8Dk3tCjXcr4lMRpfH2p+BCa9x4K9do7FHdBHhmZNah/9b i5toj4Nr6i8OOacwliEXyrdKTBJ0eWi4W7fIpxhuvTQFnltTPy0gTvaJ90sx/DIe2NSx xA==
Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2jg6xfwa04-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Jun 2018 13:23:32 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5BCLdGx020155; Mon, 11 Jun 2018 08:23:31 -0400
Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jga7vdg06-11 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Jun 2018 08:23:30 -0400
Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 11 Jun 2018 07:18:11 -0500
Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) with mapi id 15.00.1365.000; Mon, 11 Jun 2018 05:18:11 -0700
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: "huitema@huitema.net" <huitema@huitema.net>, "magnus.westerlund@ericsson.com" <magnus.westerlund@ericsson.com>, "jri.ietf@gmail.com" <jri.ietf@gmail.com>
CC: "ietf@trammell.ch" <ietf@trammell.ch>, "quic@ietf.org" <quic@ietf.org>, "ianswett@google.com" <ianswett@google.com>
Subject: RE: Adding ECN to Transport and Recovery
Thread-Topic: Adding ECN to Transport and Recovery
Thread-Index: AQHT9sK0H8sBCsQDiUuMTPA/hgyVTqRW+DkAgAAEvoCAABm1gIAAXg8AgAAm5gCAALVPgIAAQ7eAgAADFgCAAa0SAIABLgUA//+cLbA=
Date: Mon, 11 Jun 2018 12:18:11 +0000
Message-ID: <c89e100409774521b24cbe0c1167d978@ustx2ex-dag1mb6.msg.corp.akamai.com>
References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <CAKcm_gM_OHgWcJ+ktAg9BCQx1rtHc9GFg2bZG40-NcO2MoVG9w@mail.gmail.com> <CANatvzySuzK9EO13m_UQxb4wZkYW=+6By3QMU5gKXhq69gaUag@mail.gmail.com> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch> <CAKcm_gN-s0XVsGL2LLusvcm5_hp-Z5_9OFMkwph5m_bGMDbAtQ@mail.gmail.com> <55DA3F1D-2B09-4D25-9630-6BC85B68A3AF@huitema.net> <CACpbDcdTtQBLNhhiX_+wWCo-OzVvBKBpS-8RsYRcZ30xhefQZQ@mail.gmail.com>, <1023590e-83d4-bed2-640a-f5cd131677d4@ericsson.com>
In-Reply-To: <1023590e-83d4-bed2-640a-f5cd131677d4@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_c89e100409774521b24cbe0c1167d978ustx2exdag1mb6msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-11_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806110145
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-11_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806110145
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/tER8MS5vzcxPAcH7EquuNOcIUE0>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2018 12:23:49 -0000

I do not think I have seen this in the PR, so I am wondering what your recommendation is for defending against an on-a-side attacker, who sets CE bits on every EC(*) packet and races that packet to the destination? Should that be a part of this PR?

- Igor

-----Original Message-----
From: Magnus Westerlund [magnus.westerlund@ericsson.com]
Received: Monday, 11 Jun 2018, 1:15PM
To: Jana Iyengar [jri.ietf@gmail.com]; Christian Huitema [huitema@huitema.net]
CC: Brian Trammell (IETF) [ietf@trammell.ch]; Ian Swett [ianswett@google.com]; QUIC WG [quic@ietf.org]
Subject: Re: Adding ECN to Transport and Recovery


Hi,

I agree with Jana, as there are not a clear consensus lets take any further modifications of the ACK frames as a separate issue. The PR have from my perspective no open technical content issues. I will await to see if the editors or any of you have any editorial issues. But, otherwise I expect this PR to be merged quite soon.

I will now start working on a new section for a separate PR regarding the ECN black hole mitigation.

Cheers

Magnus

Den 2018-06-10 kl. 19:14, skrev Jana Iyengar:
Sounds like there's general agreement that modifying the varint to contain a flag bit will add unnecessary complexity.
Let's try to get the PR in as it is now, and if anyone really wants to go merge this and the ACK frame or rename things, let's paint that bikeshed separately.



On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>> wrote:


> On Jun 9, 2018, at 8:27 AM, Ian Swett <ianswett@google.com<mailto:ianswett@google.com>> wrote:
>
> QUIC is complex enough, I think we should just call them ACK and ACK_ECN.  A few implementations sending at least one ACK_ECN frame per connection will dispel any belief that ACK_ECN is optional.  A small amount of use will be a lot more valuable than clever naming.

Also, ECN is just one of the extensions that could be planned for ACK. Timestamps would be nice too, for those who want one-way-delay based congestion control.

-- Christian Huitema


--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>
----------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email