Bob Briscoe <bob.briscoe@xxxxxx> 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@xxxxxxx>