Re: [conex] Accounting of ConEx signals

[Bob Briscoe <[e-mail]>]

Mirja,

I agree we don't have to standardise how ISPs count 
congestion-volume. But your & Richard's question comes from a need to 
write a document defining the experimental ConEx behaviour of /TCP/, 
not an ISP meter.

Audit, not accounting, is the main reason a definitive standard 
answer is needed. We don't want to trigger the audit function into 
detecting an attack and dropping packets just because we haven't 
written interoperable documents. If ConEx signals balance congestion 
signals (drops or ECN marks) packet-for-packet, but the audit 
function checks for balance byte-for-byte (or vice versa), then the 
application could have a problem.

Altho Chris is right that you can get packet congestion, the digging 
behind the byte-pkt draft below found that byte-congestion is 
predominant on the Internet.
<http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-byte-pkt-congest/>
And the Internet is like this for good technical reasons. Designers 
of kit want the forwarding engine to still be in control when it gets 
congested, so machines are _generally_ designed so the processor can 
still cope even when the link is flat-lining with small packets.

Nonetheless, in order to push the limits on performance, some 
machines are benchmarked against a workload with a 'typical worst 
case' mix of small and large packets, rather than actual worst case 
(all small).

So I am afraid the answer is bytes: ConEx signals ought to balance 
congestion signals (drop or ECN) byte-for-byte.

This is unfortunately more difficult to implement starting from 
existing TCP code. But there's an easier answer. If you can get 
through an audit function by doing packet-for-packet signalling, when 
audit is checking byte-for-byte balance, then good luck to you. 
That's what we did in our implementation, and it seemed OK through an 
audit function checking bytes. However, we didn't yet go looking for 
scenarios that would lead to problems.

I suggest in the TCP doc we say bytes would be the ideal, but packets 
is good enough at the experimental stage. In the more general docs, I 
would ask that we say bytes, so if there are interoperability 
problems, we have a 'standard' to fall back on that is based on sound 
technical reasoning.

Finally, you are right to ask whether we should have more general 
guidance to be used when defining ConEx for other transports. We 
already have this in the two existing w-g docs (see quotes below).

<http://tools.ietf.org/html/draft-ietf-conex-concepts-uses-02>
2.1. Definitions
                 ...
    Congestion-volume:  For any granularity of traffic (packet, flow,
       aggregate, link, etc.), the volume of bytes dropped or marked in a
       given period of time.  Conceptually, data volume multiplied by the
       instantaneous congestion each packet of the volume experienced.
       Usually expressed in bytes (or MB, GB, of course).

<http://tools.ietf.org/wg/conex/draft-ietf-conex-abstract-mech-02>
3.3. Abstract Encoding
                 ...
    In both cases, the amount of congestion is signaled by the volume of
    marked data--just as the volume of lost data or ECN marked data
    signals the amount of congestion experienced.  Thus the size of each
    packet carrying a ConEx Signal is significant.
                 ...
4.4. Audit
                 ...
    To audit ConEx Signals against actual ECN markings or losses, the
    auditor could work as follows: monitor flows or aggregates of flows,
    only holding state on a flow if it first sends a ConEx-Marked packet
    (Credit or either Re-Echo marking).  Count the number of bytes marked
    with Credit or Re-Echo-ECN.  Separately count the number of bytes
    marked with ECN.  Use Credits to assure that {#ECN} <= {#Re-Echo-ECN}
    + {#Credit}, even though the Re-Echo-ECN markings are delayed by at
    least one RTT.

HTH


Bob

At 16:03 07/10/2011, Mirja Kuehlewind wrote:
>Hi John,
>
>I agree with you and Richard that usually it shouldn't make a big difference,
>but...
>
> > > In TCP if a packet get lost (with SACK) we only know how many
> > > payload got lost. We do not know the number of packets/headers
> > > that were used to transmit this data. If we would lose one big
> > > packet and then retransmit a large number of small packets instead
> > > (which are all ConEx marked) that might give quite a different
> > > ConEx signal.
> >
> >    (That's not an unreasonable case.)
>... we have to consider those kind on cases if there might be a disadvantage
>or an advantage or even the possible to cheat the policing system for some
>users.
>
>Mirja
>_______________________________________________
>conex mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design