[conex] byte-counting in conex-destopt

[John Leslie <[e-mail]>]

[e-mail] <[e-mail]> wrote:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-conex-destopt-01.txt

   In this post I treat the byte-count language added.
] 
] If the X bit is set, all three other bit (L, E, C) MAY be set. When
] ever one if this bits is set,

   I'm guessing the intent is "Whenever one of these bits is set".

] the number of bytes carried by this IP packet (incl. IP header)
] SHOULD be accounted when determining congestion or credit information.

   Implicit byte-count, IMHO, is a bad idea. Inevitably it leads to
different parties counting differently. And, we have a synchronization
problem too, where sometimes we're counting bytes in this packet and
sometimes we're counting bytes in a previous packet (at least one RTT
ago).

   There's plenty of room for an _explicit_ byte count; and IMHO if
we want to go down this path of auditing congestion volume in bytes,
we owe it to implementors to be explicit.

] In IPv6 the length can easily be calculated by the value given in
] the Payload Length header field (payload length + option space)
] plus a fixed value of 40 Bytes for the IP header itself.

   Yes, this is explicit about counting bytes-on-the-wire at IP layer;
but even so, I see room for confusion: I'd reword slightly (again,
if we want to go down this path at all).

] In principle all of these three bits (L, E, C) MAY be set in the
] same packet. In this case the packet size MUST be accounted more
] than once for each respective ConEx information counter.

   This is confusing. There's no justification given for keeping
three separate counters, nor an algorithm for how to relate them.

] In practice loss and ECN marks can not occur at the same time,

   Actually, this isn't quite true. Loss must be detected by
timeout or funky ACKs, while ECN marks are known at packet receipt.
Thus, both loss and ECN could be detected at the same time.

] so there should usually be a way to signal the respective ConEx
] information in different packets.

   "Where there's a will, there's a way..."

] In many cases if congestion occurs the sender will not sent
] additional credit bit,

   I think there's a typo there, but I'm not sure what it is...

] but if e.g. a sender assumes losses because of an audit function

   I'm not clear what is intended by "losses because of an audit
function": some proposed audit functions may actually drop packets
due to the audit information...

] or needs to maintain a certain sending rate to make an application
] layer service work, the occurrence of credit bits (c) in parallel
] to congestion exposure bit (L, E) is reasonable.

   I'm not sure I'd go as far as "reasonable", but it's certainly
"plausible".

   However, there's really no reason to believe that a sender will
desire _exactly_ the same byte-count of "credit" as "loss".

   Again, there's plenty of room for an explicit byte-count _if_
we want to go down that path.

] If a network node extracts the ConEx information from a connection,
] this node is usually supposed to hold this information byte-wise,
] e.g. comparing the total number of bytes sent with the number of
] bytes sent with ConEx congestion mark (L, E) to determine the current
] whole path congestion level.

   There's that "congestion level" term again. I'm hoping we can
avoid it...

   I remain unconvinced that _I_ want to go down the path of counting
bytes. I'd argue that in the case of packet loss, we're tending to
a active-queue-managment paradigm where drop is correlated to packet
count. (Agreed, for ECN there's a "cost" correlated to bytes allowed
through with ECN marks.) It's _hard_ to cure ISPs of thinking in
terms of percent of packets lost when they consider "congestion".

   The argument in favor of counting bytes seems to rest on "academic
purity", which IMHO will always lose to "pragmatic" in the RealWorld.

] When equally sized packets can be assumed accounting the number of
] packets (and comparing the total number to marked once) should
] deliver the same result.

   One can _always_ "assume"... :^(

] But a network node MUST be aware that this estimation can be quite
] wrong

   (That's not a correct use of 2119 MUSTard.)

   "wrong" is in the eye of the beholder. We can at most talk of
"compliant" with a standard. (And I don't believe this is the right
document for that.)

] and thus is not reliable if e.g. different sized packed are send.

   (Presumably "sent" is intended.)

   "reliable" doesn't seem the right word here.

====

   Let me argue a bit about the difficulties of synchronizing byte
counts.

   If we insist on implicit byte counts, at some point we will force
the sending of small packets to get byte counts right. (IMHO this
will lead to greater packet drops.) And, we can't drive the byte
count near zero because of IPv6 overhead. Indeed, the sender will
have to guess at IPv6 overhead, because the OS composes the actual
packet. Worse yet, no amount of jawboning in RFCs will prevent
middleboxes from fidddling with packets. :^( :^( :^(

   The smaller the packet, the greater the problem of miscounting
bytes-on-the-wire. And we can't count bytes-on-the-wire accurately
except at the node in question. Even if we could count accurately,
we don't know an appropriate estimate of byte-overhead per packet
_beyond_ bytes-on-the-wire.

   Necessarily, any useful audit function must try to match actual
congestion to congestion-expected marks. These _cannot_ happen at
the identical time: typically they're one RTT apart. But in the
'Net we work in, RTT is unknowabble except to end-points. We must,
therefore, work in approximations.

   IMHO, approximating as packet-count is much easier and not
significantly less useful. I'd really appreciate if we could stop
arguing "academic purity" and instead list problems of utility.

--
John Leslie <[e-mail]>