Despite all the detail provided further below, the
fundamentals of this approach can be summarized succinctly:

1. Software installed in the Comcast network continuously examines aggregate traffic
usage data for individual segments of Comcast’s HSI network. If overall upstream or
downstream usage on a particular segment of Comcast’s HSI network reaches a predetermined
level, the software moves on to step two.

2. At step two, the software examines bandwidth usage data for subscribers in the
affected network segment to determine which subscribers are using a disproportionate
share of the bandwidth. If the software determines that a particular subscriber or
subscribers have been the source of high volumes of network traffic during a recent
period of minutes, traffic originating from that subscriber or those subscribers
temporarily will be assigned a lower priority status.

3. During the time that a subscriber’s traffic is assigned the lower priority status, such
traffic will not be delayed so long as the network segment is not actually congested.
If, however, the network segment becomes congested, such traffic could be delayed.

4. The subscriber’s traffic returns to normal priority status once his or her bandwidth
usage drops below a set threshold over a particular time interval.

a. October 15, 2008. Comcast will have completed installation of the PacketCable
Multimedia and Internet Protocol Detail Record servers, and will have begun
installation of the Congestion Management Fairshare servers. These servers, and
other hardware used for the new congestion management practices, are described in
detail in Attachment B.

b. November 15, 2008. Comcast will have begun commercial (i.e., not trial) “cutovers”
to the new congestion management practices on a market-by-market basis.
Once the equipment is in place in a particular area, this involves Comcast installing a
software update to our customers’ cable modems in that area, launching the software
for the new protocol-agnostic congestion management practices in that area, and
disabling the current congestion management techniques in that area.

c. December 31, 2008. Comcast will have completed the deployment of all hardware
and software needed to implement our new congestion management practices, and
will have completed the “cut-overs” to the new, protocol-agnostic congestion
management practices. We will also have discontinued the protocol-specific
congestion management practices throughout our network.

How does Comcast help its customers track their usage so they can avoid exceeding the limit?

We are in the process of creating a usage meter that will measure consumption for the Comcast account which will be available in the coming months. In the meantime, we offer a meter for free with our McAfee security suite available at »security.comcast.net/

said by funchords :

So I've been thinking that there needs to be two different levels of disclosure for stuff like this. One level that has the technical nitty gritty, like Comcast's disclosures generally were today, and one that was concise but still quite accurate.

I think TK's wrap up here is in the neighborhood of that more concise version. (I'm concerned about the word "delayed," but the gist of this message isn't to pick such nits.)

Prior to these, another example I might have used would be how Microsoft sometimes handles security update notifications, but the non-techie versions of those notices seem so soft that they lose all meaning.

Traffic will be designated BE for a
particular cable modem only when both of two conditions are met:
• First, the usage level of a particular upstream or downstream port of a CMTS, as
measured over a particular period of time, must be nearing the point where congestion
could degrade users’ experience. We refer to this as the “Near Congestion State” and,
based on the technical trials we have conducted, we have established a threshold,
described in more detail below, for when a particular CMTS port enters that state.

• Second, a particular subscriber must be making a significant contribution to the
bandwidth usage on the particular port, as measured over a particular period of time.
We refer to this as the “Extended High Consumption State” and, based on the
technical trials we have conducted, we have established a threshold, described in
more detail below, for when a particular user enters that state.
When, and only when, both conditions are met, a user’s upstream or downstream traffic
(depending on which type of port is in the Near Congestion State) will be designated as BE.

Simply put, there are four steps to determining whether the traffic associated with a
particular cable modem is designated as PBE or BE:
1. Determine if the CMTS port is in a Near Congestion State.
2. If yes, determine whether any users are in an Extended High Consumption State.
3. If yes, change those users’ traffic to BE from PBE. If the answer at either step one or
step two is no, no action is taken.
4. If a user’s traffic has been designated BE, check user consumption at next interval. If
user consumption has declined below predetermined threshold, reassign the user’s
traffic as PBE. If not, recheck at next interval.

said by funchords :

Yes, which way does it go?

As a practical matter, I would presume that if the CMTS port wasn't in near congestion state, then how the packets are prioritized wouldn't matter since there wouldn't be any delay/dropping of packets.

But if the CMTS port wasn't in near congestion state, then why keep tracking at all?

said by trent25 :

Yup, that's exactly what I thought. Prioritization when there is no congestion would probably have no effect at the level of the customer experience, but why maintain the decreased priority status, as the flow chart seems to indicate.

said by jlivingood :

In terms of why not immediately release - the reason is that oscillation back/forth in BE QoS can result