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

[Bob Briscoe <[e-mail]>]

Don,

At 17:46 26/10/2009, Don Bowman wrote:
>From: John Leslie [mailto:[e-mail]]
> > Don Bowman <[e-mail]> wrote:
> >    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 an application' is not a definition of congestion, 
it's a definition of the effect of congestion on an app. Congestion 
is a property of a link (or a road, or a bus).

It makes no sense to say a road with the same number of cars on it is 
more congested if you have an important interview than if you don't.

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

I thought I had made it fairly clear, but here's more precise 
definitions (and totally precise ones are in the ref given below that).

* Link congestion is the instantaneous probability of a certain type 
of impairment at the link (loss or marking - see below).
* Path congestion is the combinatorial probability of a certain type 
of impairment at all the links on the path.

Strictly impairment is defined as "not being served to the packet's 
requirements". That doesn't mean the application's requirements, it 
means the requirements implied in the packet. I.e. a best efforts 
packet's requirement is to be delivered, and not being served to its 
requirements means being dropped. An ECN-capable packet's requirement 
is to be delivered without being marked (or dropped). A packet with a 
certain Diffserv codepoint is not served to its requirements is it's 
not delivered within the SLA for that codepoint.

For totaly precise definitions, see appendix A.1 of our original 
SIGCOMM paper on re-feedback. I must acknowledge my ex-colleague 
David Songhurst for these definitions (David started working on QoS 
in 1973 and led BT's Performance Engineering Group for many years). 
It took thought and discussion over many weeks to get these 
definitions both correct and useful in practice:

Briscoe, B., Jacquet, A., Cairano-Gilfedder, C.D., Salvatori, A., 
Soppera, A. & Koyabe, M., "Policing Congestion Response in an 
Internetwork Using Re-Feedback," Proc. ACM SIGCOMM'05, Computer 
Communication Review 35(4):277--288 ACM Press (August 2005)  DOI: 
http://doi.acm.org/10.1145/1080091.1080124


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

Again, diminishing returns and user expectation are relative to the 
app and the user. These are not objective measures of the congestion 
of a link, they are measures of the effect of congestion.


Bob



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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design