[re-ECN] What do we mean by "Congestion"

[John Leslie <[e-mail]>]

Don Bowman <[e-mail]> wrote:
> From: Bob Briscoe [mailto:[e-mail]]
> 
>> [BB] We need to unpick two separate aspects: an app both i) suffers
>> from the effects of congestion and ii) contributes to that congestion:
>>... 
>> All these differences are choices of the app, not anyone else. So
>> it's right to define an objective measure of congestion independent
>> of these things. If an app chooses to use a long RTT path thereby
>> causing more congestion, making it accountable for its contribution
>> to congestion is still the right thing to do.

   I'm afraid we do not all mean the same thing by "congestion". :^(

   While I've long since abandoned hope of getting everyone on the same
page, I believe it would help if we could keep it clear what individual
posters mean when they use that term.

   "Congestion" to historic TCP is packets lost, period.

   "Congestion" to file-transfer is anything that slows the transfer.

   "Congestion" to video-streaming is how much delay you need to
compensate for jitter and retransmissions.

   "Congestion" to VoIP is how much degradation the listener gets.

   "Congestion" to Bob is -- well, I don't know exactly: perhaps Bob
could enlighten us...

> ... Some applications have a natural pacing mechanism (e.g. video,
> voip, IM, email), others do not (e.g. file transfer).
> 
> Applications have a user-expectation of them, and an ability to deal
> with congestion. Some (e.g. the paced ones) deal with the jitter
> aspect of congestion by increasing their pre-buffer. The affect
> on the user experience (longer channel change time) is better than
> the alternative (glitches or freezes). So although congestion
> is application-independent, the effect of it is not.

   (It's important to note that adding delay to VoIP tends to degrade
perceived quality much faster than adding delay to streaming video.)

> Our equipment is able to measure VoIP QoE (MOS).

   Acronym-Alert!

> 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).

   I'll guess Don is talking about video streaming (which IMHO is
insensitive to latency below several seconds). Thus increases in
latency cover jitter nicely.

> As a correlation, we looked @ the correlation between TCP packet
> loss and MOS for VoIP.

   VoIP, of course, _is_ sensitive to latency. In my experience,
latency over half a second borders on unacceptable.

> The correlation was low (~0.1).

   Alas, I don't understand how Don measures "MOS". In VoIP, packet
loss is perceived as noise-like, and much of VoIP is pretty noise
tolerant.

> This is in a heavily mixed network w/ hundreds of thousands of
> consumer connections.

   I'm left to guess what Don refers to here...

> We inferred there was congestion @ some times because the MOS
> varied as a function of the hour.

   To be expected...

> 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).

   Alas, such assurances, unless tested, may not be dependable...
(And I'm not the least bit sure what Don means by "congestion".)

> 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).

   A correlation of 0.7 may be the best we can hope for, but it's
really not good enough.

   Round-trip-time variations are probably correlated with some
definitions of "congestion", and absolute RTTs are probably
correlated with a number of things which can degrade the experience.
Equating RTT with congestion sounds really funny, though...

--
John Leslie <[e-mail]>