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

Bob Briscoe <bob.briscoe@bt.com> Fri, 08 August 2014 13:50 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCF91B2A11 for <conex@ietfa.amsl.com>; Fri, 8 Aug 2014 06:50:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level:
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URG_BIZ=0.573] autolearn=no
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 CgWiXlUNqyXg for <conex@ietfa.amsl.com>; Fri, 8 Aug 2014 06:50:30 -0700 (PDT)
Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F0B1B299C for <conex@ietf.org>; Fri, 8 Aug 2014 06:50:30 -0700 (PDT)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 8 Aug 2014 14:50:24 +0100
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 8 Aug 2014 14:50:27 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Fri, 8 Aug 2014 14:50:26 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s78DoP4i006720; Fri, 8 Aug 2014 14:50:25 +0100
Message-ID: <201408081350.s78DoP4i006720@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 08 Aug 2014 14:50:25 +0100
To: John Leslie <john@jlc.net>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <20140807181009.GB45982@verdi>
References: <53E1377A.5010906@nostrum.com> <CAH56bmAFfZ9joDmPGRf8yy-yzwHVFZhqOW8VPsNX6e0Qa9WtCw@mail.gmail.com> <201408070851.s778p8CT002466@bagheera.jungle.bt.co.uk> <20140807120110.GA81408@verdi> <201408071433.s77EXanZ003403@bagheera.jungle.bt.co.uk> <20140807181009.GB45982@verdi>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/JtneYD8H53OW0EgQ1m9lYgymQ7M
Cc: ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] Genart LC review: draft-ietf-conex-abstract-mech-12
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 13:50:34 -0000

John,

So your argument does seem to be about not being able to allow for 
the bytes in headers on the wire (which the endpoints cannot guess). 
But you seem to have reserved the right to have other arguments. 
That's why it would be good to see all your arguments in a draft.

The conex docs have defined their solution to this problem precisely. 
Specifically across these two docs:

<http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-12#section-3.3>
    An experimental ConEx specification SHOULD describe the following
    protocol details:
       F.  If the units are bytes a definition of which headers are
           included in the size of the packet;

<http://tools.ietf.org/html/draft-ietf-conex-destopt-06#section-4>
    the number of bytes carried by
    this IP packet (including the IP header) SHOULD be accounted for
    determining congestion or credit information.

Bear in mind I have as much desire for ConEx to work as you. What 
would be the point of me definining something I didn't think would 
work? Given these definitions, here are my arguments for why the 
missing headers problem can be considered a non-problem:

1) The quantity of congestion-bytes is primarily important at policy 
devices and audit.
   1a) Audit:
       Always solely compares packets with others in the same flow,
       so any additional headers will be the same for both sides of 
the comparison.
   1b) Policing:
       If policers work in units based on a universally measureable 
definition (as above),
       it is hardly important that the actual amount of congestion 
generated was from a
       link where there were more tunnel headers or a different 
link-layer - because the
       two never have to be directly compared or related.

2) The number of additional headers that a network path adds outside 
the outermost e2e IP header during transit is not something that 
end-systems have control over. So they should not be held responsible 
for them anyway (and by argument 1 there is no reason to have to). If 
a network operator adds so many headers that it congests its links, 
well frankly it should be allowed to go bust.


Bob

At 19:10 07/08/2014, John Leslie wrote:
>Bob Briscoe <bob.briscoe@bt.com> 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
>modems).
>
>    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 <john@jlc.net>

________________________________________________________________
Bob Briscoe,                                                  BT