[conex] Fwd: byte vs packet counting

[Toby Moncaster <[e-mail]>]

Not sure if this email ever hit the mailing list…


Begin forwarded message:

> From: "T. Moncaster" <[e-mail]>
> Subject: Re: [conex] byte vs packet counting
> Date: 3 December 2011 10:10:52 GMT
> To: John Leslie <[e-mail]>
> Cc: Dirk Kutscher <[e-mail]>, ConEx IETF list <[e-mail]>
> 
> 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. However I feel things are now at a point where I can contribute something (hopefully) useful.
> 
> On Dec 2 2011, John Leslie wrote:
> 
>> 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.)
> 
> 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. 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. 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).
> 
>> 
>>  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. 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. So any customer that declares no congestion is probably not being honest.
> 
>> 
>>  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.
> 
> 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. However, on a per-packet basis audit is meaningless. Audit only has any meaning over a period of time across a given flow (or set of flows). 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.
> 
>> 
>>  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). So the function of auditing is to check that the two numbers roughly match. And yes, this is a very difficult problem to solve if you can't assume ECN is being used.
> 
> 
>> 
>>  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.
> 
> I don't think ConEx is ever meant to say to a provider "these packets are honest so must never be dropped". ConEx is meant to provide a better metric to network users to allow them to see the actual impact of any given set of packets in terms of congestion caused.
> 
>> 
>>  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. If ConEx info is unary encoded into packets then you can only measure it by measuring long streams of the packets. 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.
> 
> 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. My own view is that the second is more feasible in the real world, although the first might well be more desirable.
> 
> Toby
> 
>> 
>> --
>> John Leslie <[e-mail]>
>> _______________________________________________
>> conex mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/conex
>>