Re: [conex] Accounting of ConEx signals

[John Leslie <[e-mail]>]

Scheffenegger, Richard <[e-mail]> wrote:
> 
> I tend to agree with you - on average, there will be little difference
> between counting packets, or counting bytes;

   Thank you.

> However, if we don't agree on what is the "correct" approach beforehand
> and any box is free to account whatever, this may lead to exploits. On
> another example, if my ISP charges for the congestion volume, it is not
> irrelevant how this accounting is performed. And as soon as money is
> involved, this is a high incentive to cheat...

   Perhaps... It's not clear money _will_ be involved...

   Recall the history of long-distance phone charges: there were several
orders of magnitude difference in charges between different entities.

> IMHO, congestion volume (as defined) is measured in bytes, not packets;
> and as Conex is a IP-layer mechanism, the natural unit would be full IP
> packets (IP header + payload), which happens to be readily available by
> examining the header (although not as quick as simply accounting
> packets).

   Readily available to middleboxes, that is. It won't always be readily
available to the sender (which I presume would ordinarily be the source
of any money changing hands) or receiver (the second most likely).

> For the sender transmitting variable sized packets, this may lead to a
> different number of conex marked packets (but more accurate
> byte-congestion volume), or vice versa.

   Indeed...

   But, as an ISP, I doubt I would choose to argue the charges to the
sender based on "congestion volume" as defined by some third party.

   Also, for different tunneling (a very real consideration in IPv6
at the present), the "congestion volume" may be different at different
middleboxes. :^(

   I just don't see the value in this WG "standardizing" how to charge.

--
John Leslie <[e-mail]>