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

[John Leslie <[e-mail]>]

Bob Briscoe <[e-mail]> 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 <[e-mail]>