Re: [conex] byte vs packet counting

[Bob Briscoe <[e-mail]>]

John,

At 20:33 21/11/2011, John Leslie wrote:
>Bob Briscoe <[e-mail]> wrote:
> >
> > But audit is about checking one stream of signals against another.
>
>    "Audit" tends to imply sampling and verifying an approximate match
>of things sampled. I'm afraid we've been a bit too vague about the
>sampling ratio...

[BB]: You're thinking of random audit. There is no implication of 
randomness or sampling in the word audit alone AFAIK.


> > It is a factual function, not a policy-related function.
>
>    Umm... the sampling is somewhat policy-related...

[BB]: This debate is over whether we must define /what/ is being 
audited. Sampling is about /how/: we all agree that ConEx docs should 
not constrain the 'how'.


> > Without audit, ConEx information is unreliable for policing,
>
>    Actually, I don't agree with this. It's perfectly reasonable to
>design a policing function based on allowances, without reference to
>the accuracy of congestion prediction/responses.

[BB]: This assertion is missing one hugely important piece of 
context. ConEx information is volunteered by the sender.

As soon as the sender knows the info could be used against its 
interests, it has no reason to speak the truth. So the network will 
only use the sender's info for policing if it can verify its correctness.


> > monitoring or anything.
>
>    Oh, hardly: monitoring is the first function of research; it need
>not depend on any particular balance of the things monitored.

[BB]: As above. The situation changes drastically, as soon as 
monitored info might be used against the interests of the sender 
volunteering the information.

>
> > Imagine an Internet where it is undefined whether ConEx and
> > congestion signals should balance per packet or per byte. Then both
> > types of audit and both types of transport will be implemented.
>
>    So stipulated...
>
> > Let's assume some byte-based audit devices will discard traffic that
> > understates ConEx bytes. And some packet-based audit devices will
> > discard understatement in packets. Then these packet-balanced
> > auditors will drop byte-balanced transports. And vice-versa.
>
>    I don't agree. Knowing that some implementations count packets and
>others count bytes, it would be somewhat stupid to punish based upon
>your personal preference between these two.

[BB]: Then each type of audit function has to allow so much leeway 
that it opens a security hole the size of a bus. Even if byte-balance 
is the rule, audit security is balanced on a knife edge. Taking away 
this rule makes the security collapse.

I suggest you go away and implement your proposed audit function, or 
at least produce a pseudocode design, then evaluate its security and 
bring it to the list if it passes muster. I can assure you, there is 
absolutely no value in inventing piecemeal in this space. The value 
of the whole ConEx system depends on the integrity of the signals 
that audit assures. It's extremely tricky to get right.

There is value in brainstorming, but there is a time and place for 
such research. This ML is for standardisation. And we're late.


> > ConEx audit will become a machine for dropping large proportions of
> > packets.
>
>    I don't follow... how could "audit" be a "machine for dropping"
>anything?

[BB]: ...by the assumption above that operators use their audit 
devices to discard traffic that does not cross-check. As you yourself 
said, we cannot tell operators what to do or not to do. We have to 
assume many will discard non-compliant traffic.


> > Please explain how you propose to prevent this disaster if we leave
> > the byte-packet question open.
>
>    Actually, that's simplicity personified -- define ConEx marking
>with a byte-count field: if left blank the sender is byte-agnostic.

[BB]: OK, now you're switching to a different argument.

The integrity of this flag would then need to be protected, to 
prevent it being changed enroute (and so far ConEx integrity works 
without any crypto, implying no key management complexity).

(Give the list a little more time and I'm sure we will be able to 
think up a number of other security problems. Because the more 
flexibility, the larger the space of possible vulnerabilities.)

Flexibility is fine if it's needed, but the burden is on you to prove 
a choice between packet and byte balance is necessary.


>(Though, to tell truth, I believe such a field SHOULD be optional,
>and I see no particular reason we need it at all...)

So, that little excursion was just a waste of my time.


> > I am all for allowing flexibility in standards wherever possible, in
> > order to encourage diversity and innovation. There can certainly be
> > all sorts of implementations of the audit function, but we have to
> > minimally define whether audit is per byte or per packet - for
> > interoperability.
>
>    I'm quite happy to define it "per packet", for now...

You have to argue against the reasons given why this is the wrong choice.

The others in this discussion have all agreed that bytes is the 
correct choice. It is not sufficient to dismiss everyone else's 
arguments as irrelevant by calling them mathematical (I didn't see 
any explicit maths in the discussion, so perhaps you are objecting to 
the use of logical reasoning?).


> > Can we find some way of resolving this argument, rather than keep
> > revisiting it?
>
>    I believe _we_ could...

The only thing we agree on is that deployment must be possible.

The drafts on the table are deployable. They are based on 
implementation experience. What you're really objecting to is stating 
the goal as byte-balance, even if we allow some implementers to do it 
approximately as packet-balance. Instead you want us to say the goal 
should be packet-balance, purely because it's easier to implement (in 
the case of TCP). However, altho your argument is only over what we 
state the goal as, you're not prepared to have that argument, because 
you reject what you call 'mathematical' argument.

You have no implementation, no proposed design and you don't agree 
with arguing scientifically.

I think it's time to ask the chairs to intervene.


Bob


>--
>John Leslie <[e-mail]>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design