Re: [conex] byte vs packet counting

[John Leslie <[e-mail]>]

Dirk Kutscher <[e-mail]> wrote:
> [John Leslie <[e-mail]> wrote:]
> 
>> I sincerely hope Bob isn't saying that an audit function has to
>> evaluate _every_ packet which passes it!
> 
> Clearly, it at least has to be able to do that, yes!

   Clearly, _if_ it has to do that, we're extremely limited on _where_
we can put an auditing function. Auditing is not going to get built
into the hardware of 10-gig routers.

> Auditing is really a fundamental piece of the basic Conex mechanism,

   I'd be happy to discuss that. I see no reason to bother auditing
if the entire path is known to be free of congestion. Auditing might
make sense if you expect traffic you send to encounter congestion
later in the path, but only if you have some contractual arrangement
calling for it. (Otherwise, you can't know what the effect of
ConEx marks may be.)

   Auditing every packet is plausible near the sender and receiver,
but not in the backbone. I don't believe we have agreement among
ourselves what a receiver's uplink will do if their auditing shows
"abuse" of ConEx marking: so I don't see what auditing at the
sender's uplink can do and be confident it's the right thing.

   I suppose it's possible the experiments we do will enlighten
that question, but I'm not confident. :^(

> and has nothing to do with policy. Auditing is the basis for accurate
> congestion exposure.

   The Internet works as well as it does precicely _because_ nobody
gets too paranoid about how "accurate" packets are -- instead we
spend our efforts worrying how well the implementations of our
protocols "interoperate". (That keeps us busy enough, IMHO.)

> Only if you have that, you can think about implementing policies.

   As an ISP, I "implement policies" all the time based upon guesswork.
The general principle is that a partly-wrong policy implemented at the
right time is almost always better than a "right" policy implemented
too late.

> Having said that, it is certainly implementation-specific how
> auditing really works -- there may be tradeoffs between efficiency
> and effectiveness -- but for the sake of the discussion here, I'd
> say it's best to assume that, yes, auditing evaluates every packet.

   IMHO, it's _always_ best to assume otherwise.

   Your life will be easier if you don't depend on assumptions which
are likely to be false.

   We'd do better, when discussing this, to get specific about how
auditing might improve the use-cases we're pushing.

   Unless I misread draft-ietf-conex-concepts-uses, our principle
use case is Informing Traffic Management. I have posted before that
the most important feature of ConEx marking (IMHO) is informing
any node along the way that the sender is knowingly sending packets
despite having reason to doubt that congestion has cleared.

   Auditing does nothing to help here. The abusive thing to do is
to _clear_ ConEx marks -- and auditing can't detect that.

   I haven't yet argued a specific benefit to ECN-marking instead
of dropping -- when I do, I'll be arguing for ECN-marking well
before packets need to be dropped. I simply don't believe that any
amount of auditing will convince providers to trust ConEx marking
to mean these packets will never be dropped.

   Auditing, to tell truth, may or may not prove useful after we
have done enough experiments. IMHO, if it proves useful we'll find
that it's useful when done statistically, rather than on every
packet.

--
John Leslie <[e-mail]>