Re: [conex] byte vs packet counting

[Bob Briscoe <[e-mail]>]

John,

At 00:19 22/11/2011, John Leslie wrote:
>Bob Briscoe <[e-mail]> wrote:
> > 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.
>
>    (Usually it's easy to goad me into dictionary quotes, but today
>I shall resist.)
>
>    I sincerely hope Bob isn't saying that an audit function has to
>evaluate _every_ packet which passes it!

I am.

You might be surprised to learn that nearly every aspect of a 
communications system evaluates every packet that passes it.


> >>> 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'.
>
>    I'd prefer we didn't cast this discussion as a "debate".
>
> >>> 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.
>
>    I don't follow.

A policy device like a congestion policer using ConEx signals to 
decide which traffic to police. But the ConEx signals it relies on 
are declared by the sender who stands to lose from the policing. 
There is an (obvious) security flaw in that arrangement where the 
sender can just make up ConEx signals that suit its interests, rather 
than re-echoing actual congestion. That is solved by the network 
auditing ConEx signals against the actual congestion signalling that 
is independent of the sender (ie against actual losses or ECN marks).


>    Whether or not ConEx information is "volunteered" by the sender,
>it is unreasonable to allow an unlimited number of ConEx congestion-
>expected marks without some cost recovery.

That's true but missing the point about audit. Without audit, if the 
network imposes a limit on ConEx marks or some form of cost recovery, 
the sender could just not set ConEx marks and still cause congestion.


> > As soon as the sender knows the info could be used against its
> > interests, it has no reason to speak the truth.
>
>    Good lord, Bob: all senders already know that anything they send
>"could be used against" them.

I am guessing what you are thinking here. You might mean how much 
volume the sender sends could be used against it. You might mean the 
information the sender puts in the payload could be used against it.

But ConEx is different - the sender doesn't have to send ConEx info 
in order to communicate the payload information it wants to send. So 
the operator has to be able to make it in the sender's interest to do 
so. And we (the IETF) have to define the protocol so that operators can.


>    And the truly critical piece of information is whether the sender,
>knowing of congestion, chooses to send more before the congestion has
>cleared. Standard TCP does. Less-than-best-effort transports try not
>to.
>
>    Not all senders are evil.
>
> > So the network will only use the sender's info for policing if it
> > can verify its correctness.
>
>    "Verify its correctness" sounds like handwaving to me. IMHO research
>is needed into what heuristics would help...

Please don't read this as handwaving. Verifying correctness is what 
audit does. You can look at the code.

If you want, you can imagine the code was written randomly by waving 
a hand at a keyboard. But actually it was thought about for months, 
and every time a vulnerability was discovered, the whole 
protocol/audit system was reworked. Then the code was optimised for 
performance. And it was tested and reworked. Then reworked again. For years.

Perhaps, if you believe these things are the result of hand-waving, 
that says more about how you expect to work.


> >>> 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.
>
>    Research doesn't _need_ to work against the interests of the sender.

Eh? Perhaps s/Research/Monitoring/ ?

No it doesn't have to. But it is enough for there to be a risk. Then 
the sender will not want to tell the truth.


> >>> 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.
>
>    "Audit security" had better not be "balanced on a knife edge!"
>Whether it is, IMHO, depends far more on what you choose to punish
>than what it is the sender intends to signal.

Audit security /is/ balanced on a knife-edge.


>    (If we really need to argue "security", I'd advise seeking help
>from the Security Directorate.)

Had you not appreciated previously that ConEx is /primarily/ about 
security? Astounding.


> > 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.
>
>    That would be foolish.

What!? Are you not aware of the ground rules here? Rough consensus 
and running code.

I don't bring anything to the IETF until it has been implemented, 
tested and independently verified. Especially if it's a change to 
something as fundamental as IP.

If you or anyone else wants to play in a different ball-game, those 
of us who play by the rules are entitled to ask you to go somewhere else.


>    Before going into that much detail, we should seek WG agreement
>on what we're trying to accomplish.

That should largely be done by the end of chartering stage.

I fundamentally disagree with you here. I think everyone else does 
too. Defining an experimental protocol still requires the same 
decisions to be made as a stanrds track protc0l. It has to be 
implementable. Quickly.

>For myself, I'd like to see
>folks _want_ to turn on ECN notifications instead of drops. The WG
>discussion so far doesn't seem to be considering that a goal. :^(

This is not in the CoNEx charter.
(But I'm still pursuing this in my own company too)

However, my take is that ConEx deployment should make operators want 
to turn on ECN. I realised early on that ECN doesn't provide enough 
advantage on its own to warrant the deployment upheaval.


> > There is value in brainstorming, but there is a time and place for
> > such research. This ML is for standardisation. And we're late.
>
>    Yes, we're late.
>
>    No, we're not doing "standardization". We're producing an
>Experimental Track specification. Hopefully we'll design experiments
>and report on them, in due course.

Sorry. wrong word. But I had the right sentiment. This ML is for 
defining the experimental protocols, not musing about possible 
designs that you haven't thought through.


> >>> 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.
>
>    I don't have to assume that.

If an operator is going to rely on the info in ConEx signals to drive 
a policer, it will need an audit device (recapping the earlier argument).

If the audit device detects sender's ConEx info is lying relative to 
actual congestion info, but it does nothing about it, what stops the 
sender lying?


>    And I don't assume that operators will do much of anything at first.
>We will define ConEx signals which will be blithely ignored by the
>substantial majority of operators unless they see a _substantial_
>problem or are intrigued by a significant perceived benefit.

Yup. That's how I see it starting too.


>    There will be a few who go off on a tangent, preferentially dropping
>ConEx congestion-expected-marked packets. In our research, hopefully
>we will discover these misguided folks; and in an ideal world we'd
>convince them to preferentially ECN-mark-and-forward some limited
>amount of it. (This will not be trivial!)

I hope 'it' means all ECN-capable traffic, not just the 
congestion-expected-marked packets.


> >>> 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.
>
>    I'm willing to do so. Please state them.

All the reasons already given in this thread that you have glossed 
over, while focusing on occasional words and phrases instead of 
people's arguments.


> > The drafts on the table are deployable. They are based on
> > implementation experience.
>
>    I respect implementation experience (though I seem to have missed
>the reports of the benefits of precise byte-counting that ensued).

Ditto.


> > What you're really objecting to is stating the goal as byte-balance,
>
>    That's true, I guess -- though I've been trying to elicit reasons
>why counting packets instead of bytes is harmful before "objecting"
>on the list.

If you've been trying to elicit these reasons, it's strange you missed them.


> > even if we allow some implementers to do it approximately as
> > packet-balance.
>
>    This strikes me as a poor practice. If byte-counting is so important,
>we should set out to convince implementors to do it.

I gave the approach we can offer to do byte-counting early in the 
thread. And this is largely in the TCP modes I-D too.

The above sentence just says we don't need to insist on how 
implementers meet the goal, and they can even do packet-balance if 
they think they will get it through a byte-balancing auditor.


> > Instead you want us to say the goal should be packet-balance, purely
> > because it's easier to implement (in the case of TCP).
>
>    Ease of implementation is a strong argument when you're looking for
>widespread deployment. (I could go into other reasons, but that seems
>counter-productive.)

How many times do I have to say:
i) it's no good ONLY caring about ease of implementation, without 
caring about whether it meets a sensible goal too.
ii) the strategies in the second mail in this thread are easy to implement


> > However, although 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.
>
>    No -- I don't reject it, until I see it.

You saw it and rejected it. You have a short memory.


> > You have no implementation, no proposed design and you don't agree
> > with arguing scientifically.
>
>    I don't generally approach IETF work by first choosing an implementation,
>then arguing for it. I approach IETF work as design, trying to balance
>a lot of differing concerns.

You don't get to choose the rules. THe IETF constitution is "running code".

I'm not arguing /for/ an implementation. I'm arguing for a system 
design. Implementation gives confidence one is speaking from real 
experience. Then one can make compromises with others who made 
different choices in their design, knowing better that the new mix of 
designs will work.

What about the arguing scientifically point?


> > I think it's time to ask the chairs to intervene.
>
>    I don't ask for that -- and I think it premature until we have others
>stating that one or the other of us is disruptive.

I was asking for the chairs to intervene. I'm tired of arguing with 
someone who is working to different rules than everyone else - rules 
that don't admit to reasoning, so we can never have any way to 
determine an argument.


>    IMHO, there's been little enough traffic on this list to classify
>_anyone_ as disruptive.

Small precise discussion is far preferable to voluminous imprecise waffle.


Bob


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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design