Re: Adding ECN to Transport and Recovery

Magnus Westerlund <> Wed, 13 June 2018 14:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49C82130DC0 for <>; Wed, 13 Jun 2018 07:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z-IWTV5_ZWUa for <>; Wed, 13 Jun 2018 07:04:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BD8312F18C for <>; Wed, 13 Jun 2018 07:04:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailgw201801; c=relaxed/simple; q=dns/txt;; t=1528898655; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aHagVZWSxVRU6IoKtf28uRhhqlFwO7yDgFcAx5YAr3k=; b=QbrcsXyYg1mxV+pztbCUSZ8GzG1UGwetxFSuWqeehNFv5sSMbod/TFN5FxLKjYuJ GLjxHnmTf6wQo4VhXnjPwcPFyBq6wU/5fcZvqR3LFTfKcJyxfyCUQAQQujYLt+Ln vcTXNbKwA7v0z+B+XsNr8fCLqDRDOQ6R+R7g24Vglhg=;
X-AuditID: c1b4fb2d-5ecb19c0000055ff-1b-5b21245f4c58
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C8.C2.22015.F54212B5; Wed, 13 Jun 2018 16:04:15 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 13 Jun 2018 16:03:28 +0200
Subject: Re: Adding ECN to Transport and Recovery
From: Magnus Westerlund <>
References: <>
Message-ID: <>
Date: Wed, 13 Jun 2018 16:03:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-Originating-IP: []
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2J7iG68imK0QfMmaYueBdwOjB5Llvxk CmCM4rJJSc3JLEst0rdL4MpYMeUGa8EziYo5jzoZGxh7RboYOTkkBEwkZm+/xN7FyMUhJHCE UeLm+rlQzhZGie1nF7F0MXJwCAsYSuy46ADSwCZgIXHzRyMbSFhEQEFiTQMnSFhIwF7i4559 7CA2L5C96NQfFhCbRUBV4knnBSYQW1QgRmL1xstQNYISJ2c+AavhFHCQuPjxFzPISGag3gdb y0DCzALyEs1bZzND2OISTV9WskKs0pZoaOpghThfSeL6vOssExgFZyGZOgth0iwkk2YhmbSA kWUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmCoHtzyW3cH4+rXjocYBTgYlXh4v8gqRgux JpYVV+YeYpTgYFYS4fV7oRAtxJuSWFmVWpQfX1Sak1p8iFGag0VJnFdv1Z4oIYH0xJLU7NTU gtQimCwTB6dUA6OP1Eb5OWp5yj4F9u793ncdMta6mAtMU0yfZy7rPOWq5ae89+VqlkUbps44 +afYN+WCAbvy6SVcBT+jJv9Q2PS9i/Hv/1lc0rI5XmIhS1x8M7p1fjBsNV19I0u95MHFbWdv 1Dgd9oza2fQlUMzGz+Mg6+P2YyerghIFNhzKjfhh+XX3NM9pM5VYijMSDbWYi4oTATukxbhR AgAA
Archived-At: <>
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jun 2018 14:04:25 -0000


I have just added one more paragraph to the pull request to deal with an 
issue that arises if there is persistent ACK loss such that the sender 
never receives an acknowledgement for some packet that was actually 
received by receiver and counted in the ECN counters. To make 
implementers aware of the issue I have added this paragraph in Section 
6.6.1. Continuous Verification of ECN:

    If the acknowledgements from the receiver are lost such that one or
    more packet are received by the receiver, but never acknowledged to
    the sender an insensitivity to bleaching will be created.  In this
    situation the ECN counters reported will have increase, but the
    sender side total for acknowledged packets will not have increased.
    Thus, a number of bleached packets equal to the number of packets
    that failed to be acknowledged can be received before triggering the
    continuous verification.  To address this issue the sender detect the
    case when the ECN counters grows more than number of acknowledged
    packets when a ACK_ECN frame is received.  In such cases a new
    comparison point is created by storing the current number of totally
    acknowledged packets and latest ECN counters.  Then comparison are
    done by subtracting these stored values from the respective counters
    prior to the comparison.  Note that any out-of-order ACK_ECN frames
    can't be used for determining any loss of acknowledgements.

Please provide feedback on this addition.



Den 2018-05-28 kl. 22:29, skrev Magnus Westerlund:
> WG,
> I have been working on a Pull Request 
> ( that implements the 
> ECN proposal from the design team 
> ( into 
> something reasonably well integrated into the current drafts. Thus, I 
> think it is time that people review and consider this proposal so that 
> any issues can be addressed.
> I would very much like to present at the interim this proposal, some 
> of the choices made, and determine if there are additional changes to 
> be made before merging this.
> Cheers
> 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

Network Architecture & Protocols, Ericsson Research
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: