Matt,
I've sent suggested text to you for agreement before sending to Robert.
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). I say 'interim', because once we do the
implementation, we will see how possible this is.
I'm confident we can have a crack at it Linux.
However, I wouldn't even want to attempt it in
FreeBSD, which doesn't keep a record of packets
in flight, so it would require a complete redesign.
You may be basing your view on the accecn
presentation I gave, which was brief on this
point. In the accecn draft it says:
" If a particular sender behaviour needed to associate AccECN's
feedback of each ECN marking with the size of the original packet
that picked up the marking, there is enough information in AccECN
feedback to do so, although perhaps imperfectly. ...
...to apply AccECN to
these more challenging tasks, the Data Sender would probably have to
record the sizes and/or timings of packets in flight and combine
AccECN feedback with the cumulative acknowledgement numbers on each
ACK as well as selective ACK (SACK) information [RFC2018].
"
Bob
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-).
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)."
Â
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-.
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.
Thanks,
--MM--
The best way to predict the future is to create it. Â - Alan Kay
Privacy matters! Â We know from recent events
that people are using our services to speak in
defiance of unjust governments. Â We treat
privacy and security as matters of life and
death, because for some users, they are.
On Tue, Aug 5, 2014 at 12:58 PM, Robert Sparks
<<mailto:rjsparks(_at_)nostrum(_dot_)com>rjsparks(_at_)nostrum(_dot_)com> wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-conex-abstract-mech-12
Reviewer: Robert Sparks
Review Date: 5-Aug-2014
IETF LC End Date: 8-Aug-2014
IESG Telechat date: Not on an upcoming telechat agenda
Summary: Ready for publication as Informational
This document handles a complex description problem in a very accessible way.
Thank you for the effort that has gone into creating it.
One minor point to double-check:
This document goes out of its way to push
decisions about measuring in packets,
bytes, or other units to the concrete  encoding
proposals. RFC6789 was explicit
about conex exposing a metric of congestion-volume measured in bytes.
RFC6789 was published a couple of years ago -
has that part of it become stale?
If so, it would be good for this document to explicitly call that out.
If not, (most of section 4.6 goes back to -04 which predates RFC6789),
does this document need to retain the this flexibility in its description?
________________________________________________________________
Bob Briscoe, BT