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

John Leslie <> Thu, 07 August 2014 18:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 017BF1A0292 for <>; Thu, 7 Aug 2014 11:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.628
X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URG_BIZ=0.573] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yW9vWlCzY09L for <>; Thu, 7 Aug 2014 11:10:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 73F6D1A034B for <>; Thu, 7 Aug 2014 11:10:12 -0700 (PDT)
Received: by (Postfix, from userid 104) id B3B96C94BE; Thu, 7 Aug 2014 14:10:09 -0400 (EDT)
Date: Thu, 07 Aug 2014 14:10:09 -0400
From: John Leslie <>
To: Bob Briscoe <>
Message-ID: <20140807181009.GB45982@verdi>
References: <> <> <> <20140807120110.GA81408@verdi> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
Cc: 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 18:10:16 -0000

Bob Briscoe <> wrote:
> John,
> Please write your arguments down about byte-pkt in an Internet Draft. 

   I suppose I'm willing to do that; but I'd much prefer not to make
an Internet-Draft simply to document an argument between Bob and me.

> Then if you have a coherent argument, we will all be able to 
> understand it. I cannot understand what your arguments are in all the 
> emails you have sent on this subject; too much seems to be implied 
> rather than stated.

   Let's try a summary:

   Beyond question, it is possible for a forwarding node to count the
packets it marks or drops.

   While it is possible for a forwarding node to count bytes-on-the-
wire for packets it marks or drops, that count may not agree with such
a count at another forwarding node; and certainly will not agree with
a count of payload bytes at one end or the other.

   It is the bytes-on-the-wire which count toward congestion; and in
fact there is always _some_ per-packet overhead (though this can be
rather small near the backbone -- it is _not_ small in DOCSIS cable

   Tunnels are found in the forwarding cloud -- bytes-on-the-wire
for these is greater than a non-tunnel forwarder will see.

   Thus, I claim it rather likely that any way endpoints might count
bytes is in danger of under-counting the actual congestion.

   I have also claimed that so long as we're dealing in 1500-byte
packets, the difference between "small" packets and "full" packets
(in bytes-on-the-wire) is not great enough to justify the effort
we've been putting into trying to count bytes of congestion.

   And in practice, most transports send similar-length packets
most of the time...

> At 13:01 07/08/2014, John Leslie wrote:
>> 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.
> In case anyone on the list interprets John's use of the passive ("I 
> was purged") as implying I somehow removed him, I didn't.

   Passive voice _implies_ only that the writer didn't want to blame
a particular person. I trust our readers to know this.

> The decision was presented to me by the chairs just as it was presented 
> to John. Although I don't fully know the reasons, I doubt very much 
> that it was anything to do something as specific as byte-pkt arguments.

   That wasn't implied either...

   But perhaps we _do_ need to review that decision. :^(

   Usually I'd sleep on it before saying things like this; but I do
think there's something wrong with removing two principal editors
without the principal author knowing the reasons. Do either of our
WGCs want to comment on _that_?

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

   Appearances _can_ be misleading, I admit...

> Why would I be talking offlist with Matt if it was my intention to purge 
> him?

   True, that is not Bob's normal style.

> Everyone works off-list with their co-authors. I primarily talk 
> off-list to keep the signal to noise ratio high for postings on list.

   This isn't always best.

   The list has become near-dormant, IMHO, because folks couldn't follow
the reasoning behind announced changes to the text. (I have some reason
to believe even the _authors_ sometimes couldn't follow these.)

> We (obviously) had a huge amount of off-list discussion before 
> posting the lastest accecn draft. We put our rationale in the draft, 
> and now we've published it for review and comment by the whole WG. 
> Nothing unusual about any of that.

   I haven't yen decided whether it's worth-while commenting on accecn.
If I do, I'll mention that the complexity of Bob's "urgent pointer"
proposal is a potentially serious drawback...

>> In fact, ECN feedback _has_ to reflect packets. All the noise about
>> what senders "could" do is just rationalizing. :^(
> Not so, on both counts.
> 1) In accecn (so far), we could have reflected bytes counts (as TCP 
> does with seq nos & ack nos).

   Indeed, with a much longer TCP option, Bob could have proposed
counters for payload bytes. Need I remind anyone that payload bytes
is always less than bytes-on-the-wire?

> We chose to feedback marked packets because it should be sufficient
> to be interpreted either as bytes or packets - on the same basis that
> an ECN marking at the IP layer can be interpreted as either the bytes
> in the marked packets, or the number of marked packets. This also kept
> header overhead low enough to fit within existing fields by overloading
> - an attempt to minimise the chance of being tampered with by
> middleboxes.

   Frankly, this still sounds like rationalizing to me, but YMMV.

> 2) I deferred to Mirja & Richard for determining what senders could 
> do, given their respective expertise in Linux & FreeBSD
> implementations.

   Thank you.

>> 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_).
> What's the problem? If an ECN mark is interpreted in bytes, you just 
> add up the sizes of the marked packets, rather than counting just the 
> number of marked packets.

   Alas, Bob has always been a bit vague about what exactly he counts
when he counts bytes.

   Neither the sender nor the receiver can know what the overhead is
in terms of bytes-on-the-wire. In some cases they can't even agree
on the size of the packet as sent or received.

   I have usually guessed that Bob wishes to count payload bytes --
on which the sender and receiver _can_ agree. This, of course, would
seriously under-count bytes-on-the-wire for small packets.

   If Bob instead wants to count total-bytes-in-the-sent-packet, it
would help if he defined _how_ he wants to calculate that. (Any way
he might choose, though, will under-count bytes in some cases or
over-count bytes in most cases.)

> Or is your concern about which headers were on the packet when it
> was marked, that may have been stripped before they reach the
> transport?

   That, I suppose, is a small part of my concern...

> If that is your only concern, then we will have made progress. This 
> is something I have dismissed as an approximation error, particularly 
> given congestion counts are universally normalised into proportions 
> (marked vs total bytes, or marked vs total packets), and in general 
> all the packets will have had the same headers stripped.

   If I were happy to dismiss approximation errors, I would have
pointed out that in practice approximating bytes by counting exactly
one byte per packet (or choose any other constant number) doesn't
work that badly in practice.

   Approximation errors aren't always small; and they often tend
to go in the same direction, which becomes significant over time...

>> 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. :^(
> Constructive comment?

   I'd be happy to hear suggestions on how to restate that as such...

>> 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.
> So do I.

   Perhaps there _is_ hope -- but I'm not fully convinced. :^(

John Leslie <>