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

John Leslie <> Thu, 07 August 2014 12:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 941C21B2A80; Thu, 7 Aug 2014 05:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JyRny_ZJeH2o; Thu, 7 Aug 2014 05:01:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F033A1ABB23; Thu, 7 Aug 2014 05:01:11 -0700 (PDT)
Received: by (Postfix, from userid 104) id 3C3FFC94A8; Thu, 7 Aug 2014 08:01:10 -0400 (EDT)
Date: Thu, 07 Aug 2014 08:01:10 -0400
From: John Leslie <>
To: Bob Briscoe <>
Message-ID: <20140807120110.GA81408@verdi>
References: <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
Cc: Robert Sparks <>, "" <>, ConEx IETF list <>
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 12:01:16 -0000

Bob Briscoe <> wrote:
> Matt,
> I've sent suggested text to you for agreement before sending to Robert.

   That sentence unwittingly summarizes the story of ConEx: Bob wants
the authors to do the work, not the WG. :^(

   This is very sad. Bob is an extremely intelligent fellow with lots
of good ideas; but he's very selective in who he works with. ConEx is
a story of Bob abandoning co-authors when they questioned him too much.

   I, for example, was purged when I pointed that accurately counting
packets had to be better than under-counting bytes, and that there were
significant areas of the Internet which are not simply byte-congestible.

   Apparently Bob is getting ready to purge Matt Mathis. :^( :^(

> 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)...

   Note the "we".

   In fact, ECN feedback _has_ to reflect packets. All the noise about
what senders "could" do is just rationalizing. :^(

> 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-).

   I respect Matt: thus when he asked me to stop posting about bytes
vs. packets, I did...

>> 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)."

   Technically, it is possible for some future transport to use ECN
and count bytes instead of packets: I remain unconvinced that this
could ever _accurately_ count bytes-on-the-wire (which is what
byte-congestible _means_).

>> 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-.

   I'm afraid it's not only 6789 that's doomed. ConEx is very likely
to be shut down entirely. Right now we're being told to get on schedule;
but in essence we _can't_ stay on schedule: thus the question is whether
we'll get this draft to the IESG before we're shut down, not _whether_
we'll be shut down. :^(

>> 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.

   I would still like ConEx to produce a practical system for making
congestion visible within the routing cloud. I don't see any way for
that to happen. Thus, I simply support Matt on this question.

John Leslie <>