Re: [conex] Genart LC review: draft-ietf-conex-abstract-mech-12

Bob Briscoe <> Thu, 07 August 2014 08:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 887A61B2A0F; Thu, 7 Aug 2014 01:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gdcG0xTFvFrX; Thu, 7 Aug 2014 01:51:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E0441B29FE; Thu, 7 Aug 2014 01:51:16 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 7 Aug 2014 09:51:15 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 7 Aug 2014 09:51:13 +0100
Received: from ( by ( with Microsoft SMTP Server id; Thu, 7 Aug 2014 09:51:11 +0100
Received: from ([]) by (8.13.5/8.12.8) with ESMTP id s778p8CT002466; Thu, 7 Aug 2014 09:51:09 +0100
Message-ID: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Thu, 07 Aug 2014 09:51:08 +0100
To: Matt Mathis <>
From: Bob Briscoe <>
In-Reply-To: <CAH56bmAFfZ9joDmPGRf8yy-yzwHVFZhqOW8VPsNX6e0Qa9WtCw@mail.g>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_159965219==.ALT"
X-Scanned-By: MIMEDefang 2.56 on
Cc: General Area Review Team <>, ConEx IETF list <>, "" <>,, Robert Sparks <>
Subject: Re: [conex] Genart LC review: draft-ietf-conex-abstract-mech-12
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Aug 2014 08:51:20 -0000


I've sent suggested text to you for agreement before sending to Robert.

The issue with draft-kuehlewind-tcpm-accurate-ecn 
is different. We took the (interim) decision to 
use packets not bytes for feedback on the basis 
that the sender could then approximately 
reconstruct bytes if it needed to (because the 
sender can remember the sizes of the packets it 
sent). I say 'interim', because once we do the 
implementation, we will see how possible this is. 
I'm confident we can have a crack at it Linux. 
However, I wouldn't even want to attempt it in 
FreeBSD, which doesn't keep a record of packets 
in flight, so it would require a complete redesign.

You may be basing your view on the accecn 
presentation I gave, which was brief on this 
point. In the accecn draft it says:

"   If a particular sender behaviour needed to associate AccECN's
    feedback of each ECN marking with the size of the original packet
    that picked up the marking, there is enough information in AccECN
    feedback to do so, although perhaps imperfectly.  ...

                                         apply AccECN to
    these more challenging tasks, the Data Sender would probably have to
    record the sizes and/or timings of packets in flight and combine
    AccECN feedback with the cumulative acknowledgement numbers on each
    ACK as well as selective ACK (SACK) information [RFC2018].


At 01:02 07/08/2014, Matt Mathis wrote:
>You are correct, the section is a bit stale. Â 
>And although the authors of 6789 would like to 
>claim the topic is closed, newer documents 
>(e.g. draft-ietf-tcpm-accecn-reqs-07.txt,) have 
>found it necessary to hedge on this very issue 
>for pragmatic reasons. Â (Note the overlapping 
>authors between -abstract-mech-, 6789 and -accecn-).
>The core advice in section 4.6 still stands:Â
>"This document does not take a strong position 
>on this issue. Â  Â However, a ConEx encoding 
>will need to explicitly specify whether it 
>assumes units of bytes or packets consistently 
>for both congestion indications and ConEx 
>markings.  (see network layer requirement E in Section 3.3)."
>Some of the surrounding editorializing reflects 
>not completely resolved tension between the 
>authors on this point. Â I for one would prefer 
>to remove the presumption that 6789 and 7141 
>are the final answer, and make this draft purely 
>bytes/packets agnostic. Â I partially ceded the 
>point on the grounds that the impracticality 
>6789 would doom it over the long haul, as we have already seen in -accecn-.
>It would be bad form for this document to 
>explicitly conflict with 6789, but I for one 
>would object to it unequivocally endorsing 6789, 
>and although leaving it waffle, isn't pretty, it 
>does accurately reflect the views of the authors.
>The best way to predict the future is to create it. Â - Alan Kay
>Privacy matters! Â We know from recent events 
>that people are using our services to speak in 
>defiance of unjust governments. Â  We treat 
>privacy and security as matters of life and 
>death, because for some users, they are.
>On Tue, Aug 5, 2014 at 12:58 PM, Robert Sparks 
><<>> wrote:
>I am the assigned Gen-ART reviewer for this draft. For background on
>Gen-ART, please see the FAQ at
>Please resolve these comments along with any other Last Call comments
>you may receive.
>Document: draft-ietf-conex-abstract-mech-12
>Reviewer: Robert Sparks
>Review Date: 5-Aug-2014
>IETF LC End Date: 8-Aug-2014
>IESG Telechat date: Not on an upcoming telechat agenda
>Summary: Ready for publication as Informational
>This document handles a complex description problem in a very accessible way.
>Thank you for the effort that has gone into creating it.
>One minor point to double-check:
>This document goes out of its way to push 
>decisions about measuring in packets,
>bytes, or other units to the concrete  encoding 
>proposals. RFC6789 was explicit
>about conex exposing a metric of congestion-volume measured in bytes.
>RFC6789 was published a couple of years ago - 
>has that part of it become stale?
>If so, it would be good for this document to explicitly call that out.
>If not, (most of section 4.6 goes back to -04 which predates RFC6789),
>does this document need to retain the this flexibility in its description?

Bob Briscoe,                                                  BT