Re: [re-ECN] implementations

["Don Bowman" <[e-mail]>]

From: Leslie Daigle

> 

> Hi,

> 

> Following up an off-list suggestion -- we've heard passing references

> to

> re-ecn implementations, but it would probably be good to be able to be

> a

> bit more authoritative.

> 

> If you've done such implementation work -- I'm happy to collect

> references here and at least have a slide up in Hiroshima to list

> them/provide further pointers for people.

 

Sandvine has an 'implementation in spirit' we call fairshare traffic
management.

 

We detect the congestion in the forward path (implicitly, not
explicitly),

then act to reduce the priority of the users or applications which are
disproportionately

causing it.

 

Although specific implementations @ customers & access technologies
vary, those

basic principles are always maintained. The most common implementation
is

to enforce a 'volume accounting fairness' per subscriber, enforced only

during times of congestion. Variation on that theme include
sub-prioritisation

by application (so that the overall envelope of each user is balanced

against each other, and then within that envelope their applications are
balanced).

 

The most common implementation is to reduce scheduling priority, without

placing any fixed cap or capacity reduction. This has the affect in a
network

which is not dramatically under-provisioned of shifting the 'cost' to
the heavier

users, where the 'cost' is related to jitter, latency, and loss.

 

This is deployed in a large (well, large to us) number of residential
consumer

Access networks world-wide.

 

I understand it differs from the proposal for 'ConEx', i think that the
explicit

Exposure of congestion will be beneficial for us.

 

I'd be happy to talk in much more detail about this in japan.

 

Apologies for the HTML email and the image, but the below is an example
of the impact. 

The image shows a cumulative distribution of the round-trip latency
through the

Access network for 2 classes of user. The 'PBE' is the
priority-best-effort, the

Users who are not assigned any 'cost' for causing congestion.

The 'BE' is the best-effort group, those who are assigned the cost of
congestion.

In this particular network, the packet loss of both groups was
negligible (although

We've found packet loss to be unreliable means of measuring congestion

due to TCP rate control).

As you can see from the chart, the PBE group enjoys a situation where
almost

100% of their flows have the same latency. The BE group has a situation

where there is more significant jitter and variation in latency.