Re: [conex] byte vs packet counting

[John Leslie <[e-mail]>]

T. Moncaster <[e-mail]> wrote:
> 
> I have been purposely not contributing to this thread over the past few 
> weeks as I wasn't sure that more voices in the argument would actually
> help things.

   IMHO, _any_ additional voices would help. (Of course, I may be biased:
if nobody takes my ideas seriously it's easier to declare me "in the
rough"...)

> However I feel things are now at a point where I can contribute
> something (hopefully) useful.

   Toby has _always_ had something useful to contribute!!

> On Dec 2 2011, John Leslie wrote:
>> Dirk Kutscher <[e-mail]> wrote:
>>> [John Leslie <[e-mail]> wrote:]
>>>
>>> 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.)
> 
> I think there is a subtle difference between stating that auditing
> is a fundamental part of ConEx and saying that auditing can never
> be turned off. 

   Agreed... but it's not obvious which of these Dirk meant. :^(

> I would definitely agree that auditing is required in any network
> where there are potential trust issues and where you can't guarantee
> the whole-path network conditions.

   In other words, any real-world network...

> But I do think there are cases where it could be turned off (for
> instance in private corporate networks using conex as a means to
> control their monthly network bills).

   Is that really so different from real-world networks?

   (An aside: I talked with Matt today, and we're making progress on
understanding each other on what the WG should mean by "auditing".
Stay tuned...)

>> 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 agree, it seems hard to see how auditing something when you are
> missing half the information is going to be hard.

   (I'm having trouble parsing that sentence.)

> There are possible arguments along the lines of an ISP might make
> a decision that all users of a given access node (B-RAS or whatever)
> are likely to be experiencing roughly similar amounts of congestion.

   (Seems unlikely to me...)

> So any customer that declares no congestion is probably not being
> honest.

   This sort of assumption bothers me. What if that customer is using
a particularly good LBE protocol?

>>> 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.
> 
> My view is that we're arguing the wrong point - auditing every packet
> seems trivial if we are assuming that most routers can mark a packet
> (e.g. can do ECN). In that case they are already inspecting 2 bits of
> the IP header, so asking them to inspect a 3rd bit seems reasonable.

   (Talking with Matt today, I am beginning to understand he may be
assuming that "auditing" measures only ConEx marks versus ECN marks
for a particular packet; and that the action taken on that basis
will be simply and only dropping the packet where the imbalance is
detected, keeping no state. That much could be implemented anywhere;
but it falls far short of what we are led to believe is promised by
his "auditing function". I'm hoping the next revision will assign
more intuitive names to whatever his current "auditing function"
proposes...)

> However, on a per-packet basis audit is meaningless.

   I think I agree with Toby.

> Audit only has any meaning over a period of time across a given flow
> (or set of flows).

   There's a pretty big difference between auditing a particular
flow versus auditing the particular set of flows represented by all
traffic an ISP receives from a peer at a peering point... I'm not
sure exactly what Toby refers to here.

> There is a separate accounting mechanism where you can measure bulk
> flows of congestion, but that has to be based on a belief in the
> accuracy of the marking of the underlying individual flows.

   I don't see how that follows.

>> 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.
> 
> No. ConEx is about a balance of markings. To cheat you fail to send
> forward into the network sufficient ConEx markings to cover the
> congestion your flow is causing (or has caused).

   Not quite... an ISP can cheat by clearing marks which one sender
placed in his outgoing traffic -- that is what I meant to refer to.

> So the function of auditing is to check that the two numbers
> roughly match.

   (I note that Toby says "roughly match". Others seem to be assuming
a much stricter match. I'm afraid we don't have a clear understanding
here.)

> And yes, this is a very difficult problem to solve if you can't
> assume ECN is being used.

   I absolutely agree with Toby here.

>> 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.
> 
> I think this may point to the heart of the issue. Yes, you can sample
> to do audit, but only if you assume a relatively high density of
> markings.

   I don't follow why that is true. If auditing is not strict, sampling
should work for a wide range of density; if auditing is strict, it
will fail pretty much regardless of the density...

> If ConEx info is unary encoded into packets then you can only measure
> it by measuring long streams of the packets.

   I agree with what I think Toby intends to say: that the congestion
metric of ConEx is a fraction, not a binary function per packet.

> If ConEx is a specific number carried in each packet then sparse
> sampling may well give you enough to be able to achieve the aims of
> audit.

   Carrying what I call "congestion-expected" as a multi-bit fraction
is an interesting idea, in which I see potential benefits. I'd be
happy to discuss it, but my impression is that we're not heading in
that direction.

> Which brings me on to the aims of audit. To my mind there are two
> possible aims.
> 1) to guarantee that every single packet, flow, aggregation of traffic
>    in the network has accurately declared their congestion; or
> 2) to act as a "speed camera" that catches a sufficiently high
>    proportion of infringements to ensure that senders don't risk
>    under-declaring their congestion.

   I don't see auditing as either of these; but that may be more a
function of my tendency to think of auditing as gathering information,
not enforcing disciplinary measures based on this information.

   IMHO, "guaranteeing" much of anything isn't worth the effort over
organizational boundaries. At significant expense, we could use
cryptography to give arbitrarily high confidence to a particular
"guarantee" having come from a particular entity, but without also
signing the data "guaranteed", the effort is entirely wasted.

   (And processing all that cryptography in backbone routers seems
a non-starter to me.)

> My own view is that the second is more feasible in the real world,
> although the first might well be more desirable.

   I at least partly agree here. However, my approach to thinking
about such problems simply stops descending into details when I reach
a feasibility blockage.

--
John Leslie <[e-mail]>