John,
Please write your arguments down about byte-pkt in an Internet Draft.
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.
More inline...
At 13:01 07/08/2014, John Leslie wrote:
Bob Briscoe <bob(_dot_)briscoe(_at_)bt(_dot_)com> 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.
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. 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.
Apparently Bob is getting ready to purge Matt Mathis. :^( :^(
Why would I be talking offlist with Matt if it was my intention to purge him?
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.
> 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".
We = the co-authors (myself, Richard Scheffenegger and Mirja Kuehlewind).
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.
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). 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.
2) I deferred to Mirja & Richard for determining what senders could
do, given their respective expertise in Linux & FreeBSD implementations.
> 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_).
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. 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?
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.
>> 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. :^(
Constructive comment?
>> 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.
So do I.
Bob
--
John Leslie <john(_at_)jlc(_dot_)net>
________________________________________________________________
Bob Briscoe, BT