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

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

From: John Leslie [mailto:[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...

I would define congestion as the point @ which trying harder achieves no
more,
diminishing returns.
I would define the then affect of that in turns of user expectation of
experience.


 ...

> 
> > Our equipment is able to measure VoIP QoE (MOS).
> 
>    Acronym-Alert!
VoIP == voice over IP
QoE == quality of experience
MOS == mean opinion score, an ITU standard (ITU == international telecom
union)

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

I was actually talking about voice. Video streaming today is largely
moved to RTMP transport, and does not use RTP.

Latency to video streaming affects channel change time. Several seconds
is not great to add on to the video decode buffers (VBV). If the latency
is at all variable, some decoders are not good @ initial latency
being different than long term latency.

> 
> > 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 3GPP standard for voice is 600ms of end to end delay as an absolute
maximum (cell to cell call). In practise, 300ms is a significant
irritant
to the average person since they tend to step on each other when
talking.

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

MOS is a standard (mean opinion score) used by the voice industry. There
are methods that model the affect of loss/latency/jitter/codec fidelity
on the end user. This is crunched into a number from 1 to 5. Some
operators express a SLA (service level agreement) in terms of MOS
(e.g. 95% of calls will have a MOS of 4.0 or better).

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

I dunno, i thought it was sufficiently close to 1.0 to say 'mission
accomplished' :)

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

We correlated jitter in RTT, not absolute RTT.

--don