Re: [re-ECN] implementations

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

From: Bob Briscoe [mailto:[e-mail]]
> Don,
> 
 ...

> >
> >well, eyeball may have been a somewhat imprecise term here :)
> >
> >Our equipment is able to measure VoIP QoE (MOS). We do this by
locking
> >a local clock to the RTP stream clock, and also looking @ the RTP
> >sequence counter for detecting loss. In this fashion we can
> >see latency/loss/jitter (latency comes from RTCP-XR from the
> endpoints).
> >As a correlation, we looked @ the correlation between TCP packet loss
> >and MOS for VoIP. The correlation was low (~0.1). This is in a
heavily
> >mixed network w/ hundreds of thousands of consumer connections.
> >We inferred there was congestion @ some times because the MOS varied
> >as a function of the hour. We assumed the congestion was in the
> network
> >we were in because some of the VoIP providers were directly peered,
> >and we assumed they were uncongested (no proof of the assumption).
> >
> >In a similar fashion, we correlated access round-trip-time by
> >looking @ the delta between SYN-ACK towards the subscriber, and ACK
> >returning. We used this time as a proxy for congestion since it
> >correlated
> >better (~0.7).
> 
> [BB] Understood. But the point I was making is that we're not looking
> for some metric that correlates with each application's QoS. We're
> looking for a metric that represents potential harm by each user U on
> 'the most sensitive but unknown' application X that might be sharing
> with U. If different apps are better at working round that harm, all
> power to them.
> 
> Contribution to congestion (volume of congested bytes) might look
> like a somewhat arbitrary choice, but it's very robust because it's
> proportionate to the two factors involved, taken over a brief period
of
> time:
> - Your volume: if you're sending twice as much as someone else, you
> get twice as much pressure to get out;
> - Everyone else's volume: if the queue is being pushed twice as hard,
> it also doubles the pressure for you to get out of the way;

so the rationale for the measurement was: "Assume VoIP quality is a good
proxy for overall quality. Prove that your <product X> increases the
overall achieved quality". This was based on both pragmatic (i had
the VoIP measure available) and rational (it seems likely VoIP is
fragile) means.

We then use 'volume of congested bytes' in the approximation i mentioned
earlier: if the link is congested (defined for the current iteration
as 'over 70% utilisation') (note: we calibrated this quite extensively
in a lab see attached, but this is still an empirical approximation),
then the
users disproportionately contributing to the congestion (volume)
are offered a lower priority. The question we were trying to answer
was: did this improve the situation? What happened to the overall
experience of each class of user?

Now, how could this be improved? 'is congested' could become explicit.
I believe you are familiar w/ the concept so i won't elaborate :)
i was not suggesting 'is congested' be application specific, but
was suggesting that the 'did we make the world better' test has to
be based on application specific measurement and expectations.

I attach for reference some information on our 'calibration by
empirical means of the congestion in a cable network'. i well understand
this is not terribly generalised, but its what i have.

--don