Subject: Re: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03

From: Bob Briscoe <[email-masked]>
Date: Sun, 21 Mar 2010 13:33:40 +0000

Jason, Rich,

Following Rich's useful email on this list about how Comcast used 
congestion for traffic management within its existing business model...

It would be useful to have a section of your 
draft-livingood-woundy-congestion-mgmt detailing any changes to 
Comcast's customer contract as a result of deploying FairShare.

Even if the title says "Contractual Changes" and the text says "None".

However, I suspect there will be more to say there. You had the FCC 
looking over you, so I guess you wanted to publicly commit to being 
protocol agnostic - now that you had the technical means. I'd also be 
interested if there was any change to your Fair Use Policy, or your 
Acceptable Use Policy.

PS. What are you planning to do with the doc, and with the comments 
people have been sending - like the nine I sent (see below) and those 
Matt sent? My take would be to freeze it fairly soon, as a record of 
what you did. Rather than widen it further (which ought to go in a second doc).

Cheers

Bob

>Date: Thu, 04 Mar 2010 23:52:00 +0000
>To: Jason Livingood <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: Re: [re-ECN] Call for Comments: 
>draft-livingood-woundy-congestion-mgmt-03
>Cc: Matt Mathis <[email-masked]>, [email-masked]
>
>Jason,
>
>I had read the draft before, and it will be a useful ref. I would 
>advise that you publish soon before things move on, rather than 
>trying to add stuff on applicability to non-cable networks (even tho 
>that would be interesting - perhaps best as a separate short draft).
>
>I have some hopefully constructive comments below from my reading of 
>the latest -03 rev.
>
>
>1/

[snip]

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Jason Livingood <[email-masked]>
Date: Sun, 21 Mar 2010 18:54:37 -0400

Good suggestion to add some new content, Bob.

As to what we plan to do, your comments and others are in my I-D work queue
to be evaluated for addition into the next rev.  I might even have time to
do some of that this week, but I usually underestimate my work load during
IETF meetings.  ;-)

After that is done, I agree strongly with you that it's time to freeze it
and I hope to do so prior to IETF 78.  If in CONEX we want to take some of
the concepts and content into a new doc, that's cool but I think it's also
helpful to have an informational snapshot of the system as a stable
reference point. 

Jason

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 22 Mar 2010 13:35:42 -0700

Jason,

I don't know if you'd consider this pertinent to your draft, but it
would seem related to re-ECN/Conex area --

If I understand correctly, a monthly usage cap is combined with the
actual enforcement mechanism described in the draft. It would seem
that you have all the machinery that, in a network engineering
approximation, detects when the access network is in the state of
congestion.

The relationship between the economic (usage cap) and the technical
enforcement mechanism would seem to be, in the general sense, the
topic of Conex.

In the spirit of congestion pricing, transmitted data might count
differently towards the cap during periods of congestion and outside
of such periods. In particular, bits sent when the network isn't
congested might be counted as a fraction or not at all, and the
overall cap could be adjusted.

Additionally, the "Exposure" part in "Congestion Exposure" might be
related to making the current measured state of the network and of the
subscriber's line known to the subscriber.

It might even be that the two are related: If the user doesn't know
when the network is congested, how can he change the utilization
patterns to relieve the congestion?

I'm sure you've given this a lot of thought. Anything you could share?

Thanks,  -- Stas

On Sun, Mar 21, 2010 at 3:54 PM, Jason Livingood
<[email-masked]> wrote:
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
>

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com

---

From: Jason Livingood <[email-masked]>
Date: Mon, 22 Mar 2010 15:04:03 -0700

Inline below
- Jason

> approximation, detects when the access network is in the state of

In operation these are independent processes, though both usage metering and
congestion management rely upon volumetric accounting data contained in IP
Detail Records (IPDR).  Also, someone could certainly exceed such a usage
limit without necessarily contributing heavily to congestion.  So tool each
has its place.  The usage limit is a tool to help maintain a flat-rate price
structure and the congestion management system helps distribute the effects
of congestion (should it occur) upon the users contributing most heavily to
said congestion at the time of congestion.
 
> enforcement mechanism would seem to be, in the general sense, the

Agreed.

> overall cap could be adjusted.

Indeed!  The first step though is to establish the basic byte accounting
system we have now*, after which it's possible to contemplate the kinds of
extensions you describe.  It would be interesting to be able to
differentiate between congestion contribution usage, regular usage, and less
than best effort usage, and to vary how these are counted as you describe.

* When I say we have it now, the backend systems are in place but we're
still mid-way through rolling out a user-facing usage meter.  We're more
than 50% complete and have deployed it to millions of users in just the past
few weeks.  The meter looks like this:
http://networkmanagement.comcast.net/datausagemeter.jpg
And this is an independent analysis of our meter system:
http://netforecast.com/documents/NFR5101_Comcast_Usage_Meter_Accuracy.pdf

> subscriber's line known to the subscriber.

Agree

> patterns to relieve the congestion?

I think this is a very good point.  And by user adjustment, I include
applications in that as well so that an app could choose via its logic to
make real-time adjustments - though exposure to users is interesting as well
since this can influence application choice, application usage and settings,
etc.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 22 Mar 2010 23:22:23 +0000

Stas, Jason,

responses to you both inline...

At 22:04 22/03/2010, Jason Livingood wrote:
> > of such periods. In particular, bits sent when the network isn'ts to you

Just to be clear, ConEx (if done as re-ECN) doesn't have to be 
mediated by any central management system that detects when the 
system is congested and triggers 'network congested mode'. When 
queues are marking packets beyond their AQM threshold, more of the 
volume will be marked, and when they're not it won't. Simple.

>than best effort usage, and to vary how these are counted as you describe.

If you just count marked congestion-volume, it just works. You don't 
have to know that a transport is LBE. The network just measures less 
congestion when that app is using the net, merely because it is 
causing less congestion.

Bob