Re: [conex] byte vs packet counting

[John Leslie <[e-mail]>]

Toby and Bob raise a number of points I will follow-up in separate threads,
but one point deserves to be in this thread.

Toby Moncaster <[e-mail]> wrote:
> On 13 Dec 2011, at 20:12, Bob Briscoe wrote:
>> At 09:50 06/12/2011, Toby Moncaster wrote:
>> 
>>> The whole core of this argument (should you account for bytes or
>>> packets) has always been a major bone of contention between me and
>>> Bob. Not least because it can be impossible for a sender to comply
>>> (it is very easy to construct pathological sequences of packets
>>> where the sender is forced to either over or under declare if they
>>> are doing per-byte auditing). I think this is a case where the
>>> IETF view has to diverge from the researcher's view. In the IETF
>>> we have to make prosaic engineering decisions. Personally I would
>>> like ConEx to account on a per-packet basis, BUT with an allowance
>>> for it to be more accurate if an operator so wishes
>> 
>> [BB]: that's my position too.
>> Assuming "more accurate" means per-byte.
> 
> That was my implication, yes ;)

   I must dissent on calling per-byte "more accurate" than per-packet
when the number of packets is clearly defined and the number of bytes
is inferred (and in at least some cases, inaccurate).

   Bob seems immovable in his belief that per-byte accounting is
"more correct", despite a number of posts showing cases where the
per-packet overhead dominates.

   I feel just as immovable in claiming that neither will _always_
dominate. I prefer counting packets because it's simpler; I'm willing
to count bytes if a clear benefit is demonstrated during Experimental
phase.

   Thus it's time for a specific proposal in compromise.

   I propose that the ConEx Destination Option carry a 16-bit field
for byte-count, and this field be optional -- both for the sender to
fill or not, and for any node along the path to check or not.

   Thus, during the Experimental phase, any sender could set it and
see what changes (if anything); and any node along the path could
gather data on actual variations in this number and draw conclusions
about potential benefits of its use.

   IMHO, unless senders voluntarily set it and at least some nodes
voluntarily use it, there _can_be_ no benefit. But I'm willing to
leave the field in place against a possible future use. (I hope to
live long enough to see 4k packets become common in the wild; this
could expose a greater benefit from considering bytes per packet.)

   I'm not willing to "go along" with Bob on _inferring_ a byte count
and calling that more accurate; but I'm willing to accept an explicit
byte count with exact details of how the auditing function may use
it left for future work.

--
John Leslie <[e-mail]>