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

[Bob Briscoe <[e-mail]>]

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 <[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.

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

________________________________________________________________
Bob Briscoe,                                                  BT