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.
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 <john(_at_)jlc(_dot_)net>