Subject: [p2pi] Follow-Up from Comcast Presentation

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 6 Jun 2008 20:04:17 -0400

As a follow-up to our presentation of last week, on slide 3 we cited
some of our key focus areas, which were improved/increased transparency,
disclosure, openness, and fairness.  We hope we took some steps in that
direction in the overall slide deck.  Beginning on slide 11 we went into
a good level of detail on technical trials of a new network management
technique, which was protocol-agnostic.  

Related to this, we now have a new FAQ on our website about those trials
at
http://help.comcast.net/content/faq/Frequently-Asked-Questions-about-Net
work-Management#technique .  Also, customers in those trial markets have
received an email that explains details about the trial, which is
started yesterday.  Additional information is also available to
subscribers via a link in our Terms of Service, directly to
http://www.comcast.net/terms/network/ .  In addition, on slide 10, we
described speed upgrades for our customers that should now be in place.

As noted during our presentation, we continue to be interested in
specific feedback on the method described.  We hope to be able to share
trial results at some point, and in some TBD form.  Perhaps that will be
possible by the time IETF 72 rolls around.  I know I had some private
follow-ups with folks like Henning as well, and will get to some of
those next week.

Regards
Jason

_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Robb Topolski" <[email-masked]>
Date: Fri, 6 Jun 2008 21:09:47 -0500

My feedback is that discrimination based on user-history is no better than
protocol-discriminatory behavior. Just as the Internet Standards do not lead
developers to expect a network that discriminates against a protocol, those
same standards do not prepare developers for a network that is
discriminating based on nebulous concepts of "fairness."

In particular, I'm concerned with possible scenarios such as someone who is
mid-upload of 1100 European vacation pictures (all at 8 Megapixel) when her
husband has a medical emergency.  She dials 9-1-1 on Vonage or whatever
non-Comcast VOIP device. Comcast delays and drops her packets as the new
system places her VOIP call is behind long packet queues created by other
activity in her neighborhood.

Another set of scenarios pertains to users, applications, or devices
reserving bandwidth that should be available to them within their teir, and
the unexpected malfunction when the bandwidth that they purchased is not
available.  First, there is the RSVP scheduler native to Microsoft OS's for
many years. Second, there are applications like NetLimiter, where
responsible and savvy users can segment their bandwidth or keep certain
applications under control  Third, and ironically, almost all P2P
applications have upload bandwidth limiters.  Users are generally advised to
set these to less than their subscribed bandwidth so as to allow other
Internet uses (such as VOIP calls).  Finally, there are many consumer
hardware devices that allow users to tune prioritization.  For example, many
consumer gateway-router devices marketed under different brands use a QoS
engine by Ubicom.  These devices determine the upload stream size either as
manually configured by the user or measured automatically when the router
reboots.  These devices will not function properly if the bandwidth it
believes it is reserving is suddenly made unavailable by the network.  In
summary, best-effort traffic is the baseline traffic expectation and
developers of Internet products do not expect a situation where a network
operator has invented a "worse than best-effort" traffic class -- nor should
they.

The issues are, likewise, the same as with protocol discrimination.

The users are harmed because their network is behaving strangely and they
have no way of knowing why.  The devices that they buy at the store with the
system requirements of "Broadband Internet Connection" do not work on their
connections.  There is no notice before, during, or after their traffic is
deprioritized.  And finally, they suffer a very non-technical consumer harm
in that they receive less than the plan that was marketed and sold to them.

Innovation is harmed because the access and transit networks continue to
behave unexpectedly.  It isn't the network operator who will get the call
about the online game or VOIP application that is behaving poorly, it's the
software publisher.  I particularly worry about how the binary nature of
this "penalty box" will look to users (when all traffic is either
prioritized or not, deprioritized traffic suffers significant degredation as
only it is fighting for the limited resource).  Normally, a sustained amount
of network congestion slows everyone relatively equally and smooths out the
effects -- and this effect is rather well recognized as a congestion
effect.  Therefore, such behavior will deflect calls for help to publishers
and manufacturers of networking products, driving up their costs and
decreasing their willingness to invest in new bandwidth-eating applications.

And lastly, this is bad for the future growth of the Internet.  Allow me to
editorialize, please -- this will not be technical.  During my career at the
worlds largest chip manufacturer, our products (almost by definition)
followed a very "Moore's Law" capability curve.  If the CPU overhead was not
going to be available, then why develop software with richer detail,
smoother video, and deeper sound.  The USA actually does enjoy among the
better broadband speeds (not the best, but at the knee of the curve
http://news.bbc.co.uk/2/hi/technology/7098992.stm), even though the Cable
industry is clearly overpromising and underdelivering (
http://arstechnica.com/news.ars/post/20080228-att-talks-serious-smack-about-cable-broadband-speeds.html).
Comcast is sending the signal that the operators of the access  networks are
going to tamp down the natural demand-based growth of the internet is as
uninteligent as a chip manufacturer saying that they're done making faster
chips.  So why would someone release a bandwidth-hungry product into that
environment?  Just as the world's largest chip manufacturers enable
innovation by trying to stay as far ahead of developers ability to suck-up
MIPS as possible, I would expect someone serious about leading in the
business of broadband should be doing the same.

Thanks for asking for feedback.  I'm sorry it is not at all positive.  While
I do recognize efforts at more transparency and user notification as good
things, the method itself fails the standards compatibility test.

Robb Topolski

On Fri, Jun 6, 2008 at 7:04 PM, Livingood, Jason <
[email-masked]> wrote:

> work-Management#technique<http://help.comcast.net/content/faq/Frequently-Asked-Questions-about-Network-Management#technique>.  Also, customers in those trial markets have

-- 
Robb Topolski ([email-masked])
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 6 Jun 2008 19:56:08 -0700

On Jun 6, 2008, at 7:09 PM, Robb Topolski wrote:

> My feedback is that discrimination based on user-history is no  
> better than protocol-discriminatory behavior. Just as the Internet  
> Standards do not lead developers to expect a network that  
> discriminates against a protocol, those same standards do not  
> prepare developers for a network that is discriminating based on  
> nebulous concepts of "fairness."

THis is a RIDICULOUS notion.

And "Fairness" doesn't have to be nebulous.  "In the periods of  
congestion, when there are N users competing for traffic, no user will  
get more than 1/N - epsilon of the available bandwidth, measured as a  
running average over 10 seconds and 10 minutes".

A nice concrete definition, that would INSTANTLY prioritize small  
flows over large flows, and interactive flows over bulk flows, when  
examined between users.  Its what users really expect when you talk  
about "fairness".

> In particular, I'm concerned with possible scenarios such as someone  
> who is mid-upload of 1100 European vacation pictures (all at 8  
> Megapixel) when her husband has a medical emergency.  She dials  
> 9-1-1 on Vonage or whatever non-Comcast VOIP device. Comcast delays  
> and drops her packets as the new system places her VOIP call is  
> behind long packet queues created by other activity in her  
> neighborhood.
>

So you'd rather her not be able to make a VoIP 911 call because  
someone ELSE on the same subnet is running BitTorrent grabbing  
"Indiana Jones and the Latest McGuffin"?

In fact, this is EXACTLY the case why ISPs need to do both INTER user  
fairness (to ensure that everyone gets some reasonable allocation,  
because TCP DOES NOT PROVIDE THIS AS THE APPLICATIONS ARE USED!) and  
INTRA-user shaping to prioritize small flows (a simple "prioritize  
smaller flows" instantly ensures that VoIP still works).

Yes, we can all dream of the utopia where the picture upload knows  
that its a picture upload and the VoIP call knows its a VoIP call and  
the networking signaling takes care of itself.  But with all the  
crappy NAT boxes (eg, which randomly inject RST packets into active  
flows!), crappy end host software, and crud in between, if you want  
the VoIP call to have priority, the ISP must infer that it is a VoIP  
call and treat it as such, because otherwise the old devices, with  
their many limitations, will mess up your signaling.

But until then, INTER user fairness is essential, because without it,  
the net can't operate in the flat-rate billing model.

> reserving bandwidth that should be available to them within their  
> teir, and the unexpected malfunction when the bandwidth that they  
> purchased is not available.

If you want a DEDICATED 10 Mbps, rather than a statistically  
multiplexed 10 Mbps, pay for it!  It costs ~$1000 a month or so for a  
reason.  Or pay-per-bit, in which case the ISP would be happy to not  
do any traffic shaping at all, because your bit is worth the same as  
your neighbors.

But in the flat rate world, heavy users traffic is less valuable to  
the ISP, and damaging to the light users.  Remember, you may have  
5000+ users sharing a single 1 Gbps uplink.  Yes, they have a "16  
Mbps" download, but it only works because not everybody is downloading  
at full rate at the same time.

And notions of network enforced fairness should not mess up the dream  
of devices which do proper scheduling: NO network device should, or  
CAN assume that the bandwidth is fully committed to it.  Otherwise,  
why would you have congestion control?

---

From: "Robb Topolski" <[email-masked]>
Date: Sat, 7 Jun 2008 10:52:04 -0500

> THis is a RIDICULOUS notion.

I would have expected a better choice of words, Nick.

> And "Fairness" doesn't have to be nebulous.  "In the periods of congestion,
> when there are N users competing for traffic, no user will get more than 1/N
> - epsilon of the available bandwidth, measured as a running average over 10
> seconds and 10 minutes".

It seems that we both agree this would be an improvement, but still not good
enough unless codified somewhere (suggested, vetted, approved, and made
Internet Standard by the IETF).

> A nice concrete definition, that would INSTANTLY prioritize small flows
> over large flows, and interactive flows over bulk flows, when examined
> between users.  Its what users really expect when you talk about "fairness".

I think you will agree that users don't know about flows, and developers
might think fairness means the equal opportunity to send at any given moment
despite what happened milliseconds ago.

>
>  9-1-1 scenario (emergency call, 999, etc.)
>>
>
> So you'd rather her not be able to make a VoIP 911 call because someone
> ELSE on the same subnet is running BitTorrent grabbing "Indiana Jones and
> the Latest McGuffin"?
>

Anything that is popular is popular because it works on the Internet --
warts and all.  There is nothing out there that depends on prioritization as
the differentiating factor between "working" and "not working."
Prioritization simply makes such real-time applications more robust.  99% of
the time, the Internet is fine.  Prioritization helps certain applications
during that 1% of the time.  (brown numbers disclaimer)

Yes, we can all dream of the utopia where the picture upload knows that its
> a picture upload and the VoIP call knows its a VoIP call and the networking
> signaling takes care of itself.

This is not my utopia.

> But with all the crappy NAT boxes (eg, which randomly inject RST packets
> into active flows!), crappy end host software, and crud in between,

The solution to interference by non-Standards-conforming devices should not
be adding additional non-standards-conforming devices.

if you want the VoIP call to have priority, the ISP must infer that it is a
> VoIP call and treat it as such, because otherwise the old devices, with

You have missed my point, and perhaps others did to.  Note the word priority
does not exist in the following paragraph, nor is any signalling mentioned:

Best-effort is the baseline expectation of innovators creating products for
the Internet -- even with some congestion thrown in.  They design their
products to work in such a network.  They cannot expect that network
operators will invent worse-than-best-effort class that dramatically changes
the characteristics of the network from one moment to the next.

> But until then, INTER user fairness is essential, because without it, the
> net can't operate in the flat-rate billing model.

I'm certain that it can, if not for all, for most.

According to the NCTA, this is a problem caused by a very few users.  That
statement doesn't pass the smell test, however.  I think that the market
demands and competitive abilities for more symmetrical connections in the
last mile have outstripped Cable's ability to keep up with it.

I think that these are not technical problems, these are willful business
choices in approaching the market: Cable Internet is shaping the future by
shaping the traffic in the present because it serves many of their business
interests to do so.  Perhaps the business interest is simply to avoid
increasing costs related to bandwidth growth; perhaps it is more.  Either
way, the follow-on consequence is limiting the options to consumers who are
distracted from watching television by the many competing choices on the
Internet.

The beauty of the Internet Standards is that they hold no such motives or
bias.  They are EE/CS's answer to MBAs as to what should and should not be
happening on the 'Net.

>> available.
> If you want a DEDICATED 10 Mbps, rather than a statistically multiplexed 10
> Mbps, pay for it!  It costs ~$1000 a month or so for a reason.  Or
> pay-per-bit, in which case the ISP would be happy to not do any traffic
> shaping at all, because your bit is worth the same as your neighbors.
>
> But in the flat rate world, heavy users traffic is less valuable to the
> ISP, and damaging to the light users.  Remember, you may have 5000+ users
> sharing a single 1 Gbps uplink.  Yes, they have a "16 Mbps" download, but it
> only works because not everybody is downloading at full rate at the same
> time.
>

Nicholas, everything you said above is true.  It is also beside the point to
everyone on this list -- we understand the technical implications of the
shared nature of their Internet connection.  Grandma and Grandpa Farmer or
Mr. and Mrs. Factory Worker do not and should not have to understand
overbooking (or statistical multiplexing, or bandwidth aggregating, or
whatever).

The ISPs control the sizes of the shared pools of bandwidth, the number of
consumers who share it, the prices of admission, and the size of the pipes
between a subscriber and the pool.  They have total control and purview over
those variables.  Controlling these variables to ensure that everyone has a
good experience is Reasonable Network Management.

Regardless of how ISPs structure the offering, the end effect has to be
Internet access that works reliably for subscribers who are using the
Internet within those parameters. A major ISP offering Internet service that
fluctuates wildly between working and not-working well is bad for the entire
community!

More and more, people and businesses rely on the internet.  If it becomes
perceived as unreliable, it is much less valuable and the network will
shrink. Today, common advice in VOIP forums is to not rely on your provider
for 9-1-1 calls.  Regardless of the actual soundness of such advice, we
should be working toward a day where such advice is universally dismissed
due to the actual increased reliability of Internet services and
infrastructure.

Users, unnovators, service providers, and even operators should all be able
to rely on the fact that the Internet does not and will not behave
unpredictably from one segment to the next, from one moment to the next, or
from one protocol to the next.

> NO network device should, or CAN assume that the bandwidth is fully
> committed to it.

That is good advice, but it is not yet understood.  Even the most savvy
network developers expect that once the network is accurately detected or
described into its configuration, that it does not change from moment to
moment.

There's a story some of the Comcast guys told me about Apple iChat and
Powerboost.  Your advice would have helped the iChat developers avoid some
headaches.

But, you weren't thinking of these things -- you were thinking about
congestion...

> Otherwise, why would you have congestion control?
>

Unlike your advice above, everyone understands that congestion happens.
Some congestion on the Internet is expected from time to time, and
developers work in enough robustness.  But, nothing is really expected to
work well through a system that is *cronically clogged*.  Current
congestion-control algorithms are quick and are sufficient for taming
momentary spikes in congestion.

Comcast is not talking about relieving spikes of congestion.  Instead, they
are moving toward *prolonged congestion as a planned operational mode*.  As
I pointed out, they have announced that they are tripling their upload
speeds (presumably even though the underlying shared pool of bandwidth has
remained the same as these increases are not related to DOCSIS3
deployment).

Comcast would only need to invent this new method unless they have abandoned
expectations to keep the amount of available bandwidth well ahead of their
consumers' demand for it.

---

From: John Leslie <[email-masked]>
Date: Sat, 7 Jun 2008 13:39:25 -0400

Robb Topolski <[email-masked]> wrote:
> 
> Best-effort is the baseline expectation of innovators creating products
> for the Internet -- even with some congestion thrown in.  They design
> their products to work in such a network.  They cannot expect that
> network operators will invent worse-than-best-effort class that
> dramatically changes the characteristics of the network from one moment
> to the next.

   I strongly recommend we avoid the term "worse-than-best-effort" --
it is unlikely we can agree on a common meaning for it.

   Obviously Robb likes the connotations it brings (and dislikes the
idea of such a beast); but others are using the term to mean something
which _could_ be reasonable.

   Rather than try to agree on a term, I suggest we instead invest the
time to write words that say what we actually mean.

> According to the NCTA, this is a problem caused by a very few users.

   That's at least partly true -- today.

   Part of our job is to convince them that only a sucker would bet it
will still be true six months from now.

> I think that the market demands and competitive abilities for more
> symmetrical connections in the last mile have outstripped Cable's
> ability to keep up with it.

   I wouldn't put it quite that way. However, market demand is already
seriously taxing Cable ISPs' _practices_ for keeping up with it.

> I think that these are not technical problems, these are willful
> business choices in approaching the market: Cable Internet is shaping
> the future by shaping the traffic in the present because it serves
> many of their business interests to do so.

   That bears repeating.

   Cable ISPs don't enjoy great support from Corporate management. Most
sales are for combinations of services, and Corporate management is used
to thinking ten-year depreciation schedules which can be stretched to
twenty to improve quarterly profits.

> Perhaps the business interest is simply to avoid increasing costs
> related to bandwidth growth...

   Absolutely.

> The ISPs control the sizes of the shared pools of bandwidth, the
> number of consumers who share it, the prices of admission, and the
> size of the pipes between a subscriber and the pool. They have total
> control and purview over those variables. Controlling these variables
> to ensure that everyone has a good experience is Reasonable Network
> Management.

   ... but what Corporate management wants is to serve a mass market.

> A major ISP offering Internet service that fluctuates wildly between
> working and not-working well is bad for the entire community!

   Correct!

   So long as Corporate management believes they can avoid those
fluctuations by eliminating "bad users", they will try to do so.

> Today, common advice in VOIP forums is to not rely on your provider
> for 9-1-1 calls. Regardless of the actual soundness of such advice,
> we should be working toward a day where such advice is universally
> dismissed due to the actual increased reliability of Internet
> services and infrastructure.

   I'm not sure that is a reasonable goal for Cable ISPs. Telco ISPs
can certainly get there, and independent ISPs are already there; but
Cable ISPs are perceived as cost centers, not profit centers.

> Even the most savvy network developers expect that once the network
> is accurately detected or described into its configuration, that it
> does not change from moment to moment.

   Another misconception we should try to cure. (I'm not holding my
breath!)

> developers work in enough robustness.  But, nothing is really
> expected to work well through a system that is *cronically clogged*.

   Nonetheless, chronic clogging has been a local feature as long as
there has been an Internet.

> Comcast is not talking about relieving spikes of congestion.
> Instead, they are moving toward *prolonged congestion as a planned
> operational mode*.

   Actually, I disagree: they are perfectly willing to shed the
customers they believe are causing congestion.

> As I pointed out, they have announced that they are tripling their
> upload speeds

   (because that's what a DOCSIS upgrade promises for "free")

> (presumably even though the underlying shared pool of bandwidth
> has remained the same as these increases are not related to DOCSIS3
> deployment).

   Upstream _transport_ (to the "backbone") is pretty cheap. Last-mile
upstream is congested because of design choices (the technical term
IMHO is "mistakes") of DOCSIS upstream scheduling). I am not privy to
actual DOCSIS 3 specs; so I don't know whether these "adverse features"
have been fixed.

--
John Leslie <[email-masked]>
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Joe Touch <[email-masked]>
Date: Sat, 07 Jun 2008 10:48:27 -0700

> it is unlikely we can agree on a common meaning for it.

Least effort?

Joe

---

From: John Leslie <[email-masked]>
Date: Sat, 7 Jun 2008 13:57:12 -0400

>> it is unlikely we can agree on a common meaning for it.

   Not a bad term... ;^)

   But can we actually _agree_ on a meaning for it?

---

From: Joe Touch <[email-masked]>
Date: Sat, 07 Jun 2008 11:05:14 -0700

>    But can we actually _agree_ on a meaning for it?

Least effort = the first traffic dropped in a the presence of congestion

That means it would lose to best effort, though.

In some cases, that's what you want. In other cases, you want something 
that basically loses to TCP, but competes with current best-effort 
normally. That's just best-effort, AFAICT.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 07 Jun 2008 14:09:48 -0400

Several of the meeting presentations referred to "Scavenger service".

As a definition, assuming I am allowed to define using diffserv, how about:

Unmarked packets, and packets marked for better diffserv classes will 
receive preferential queueing treatment compared with those marked with 
Scavenger class service.  To avoid starvatation, the Scavanger queue 
will be guaranteed a minimal percentage (10%?) of the data capacity even 
when normal and better services could consume all available bandwidth.

That is basically the inverse of the simplified EF definition, for 
achieving essentially the opposite goal.

Joel

---

From: John Leslie <[email-masked]>
Date: Sat, 7 Jun 2008 15:15:09 -0400

> achieving essentially the opposite goal.

   Hmm... we really _ought_ to be able to define "scavenger service"...

   To me, "scavenger service" implies that the application is happy to
see some periods -- say ten minutes or more -- where no packets are
getting delivered at all, so long as the connection isn't lost.

   (Of course, this definition starts to fall apart at inter-planetary
distances...)

---

From: Nicholas Weaver <[email-masked]>
Date: Sat, 7 Jun 2008 12:23:39 -0700

There is always just "friendlier than TCP-Reno under reasonable ranges  
of latency and bandwidth" as a definition, so conventional TCP flows  
will outcompete the "scavenger" service.

Of which there are plenty of examples, including TCP-vegas, of stable  
congestion control algorithms which have this property.

So the question is not "How do you do this?" but "Why is this not  
done?".

I believe that the Linux stack, for example, allows you to switch the  
behavior of newly-created flows from Vegas to Reno with a /proc update.

---

From: Richard Bennett <[email-masked]>
Date: Sat, 07 Jun 2008 12:54:48 -0700

This is an interesting discussion. By way of introduction, I'm mainly an 
IEEE 802 guy, having contributed to 802.3, 802.11, and 802.15.3a, but I 
did have some input into RFC 1001 and 1002, and have worked on Bandwidth 
Brokers to support video conferencing and that sort of thing for a 
while. I think some combination of Re-ECN and Diffserv will solve the 
congestion problem that we see on primarily on Layer 2 networks thanks 
to increased use of P2P.

In the 802.11e/Wi-Fi Alliance WMM world, we created four priorities that 
are easily mappable to DSCP and 802.1d VLAN tags: Voice, Video, Best 
Effort, and Background. The worse-than-best-effort service is 
Background. WMM is implemented in all the wireless NAT boxes that have 
sold over the last three years or so, so it's basically the status quo 
model for residential networks. In the early days of the Internet, 
during the Great Switchover period, the default Layer 2 was DIX 
Ethernet, a single service system, but nowadays Wi-Fi is a major part of 
the Layer 2 scenario with its four service classes. We could do worse 
than see how to smoothly integrate this sort of Layer 2 service into the 
IETF stack.

David Clark made the observation at the FCC hearing in Cambridge that it 
would be nice for the network to communicate its congestion state to 
applications a priori, so that applications would make decisions about 
how to handle current conditions. This strikes me as a wise enhancement. 
It would no doubt be facilitated by a system that improved 
layer-to-layer communication within the stack.

IEEE 802 goes to great pains to describe Service Access Points at each 
layer and a variety of return codes for accessing functions. In 
principle a Layer 3 function desiring a specific priority from Layer 2 
can simply ask for it when presenting a packet, and be told if it got 
what it wanted. In practice, the DiffServ model of tagging packets with 
priority can be married with 802.11e/WMM through what we call a 
Convergence Function in 802 land. The 802.11e standard actually 
describes one, but I'm not sure it's right.

We probably won't make much progress here if we engage in too much 
hand-waving and opining about the old days of the Internet and what 
assumptions developers may or may not have, so it's probably wise to 
stick to specifics as Nick has below.

Richard Bennett

---

From: "Robb Topolski" <[email-masked]>
Date: Sat, 7 Jun 2008 17:27:07 -0500

responses inlined --

> which _could_ be reasonable.

On the contrary, I have no particular affection for the term at all.

I simply mean Comcast's new (under trial) traffic classification for traffic
from heavy bandwidth users.  Since most would assume that "best effort"
describes the undifferentiated traffic from subscribers, traffic that comes
from Comcast's "affected" users will be dropped or delayed more often than
"best-effort" traffic.

That was not an attempt to word-smith, and please do not read in malice
where there is none intended. The above description is simply easily
summarized as "worse-than-best-effort."

I apologize that my post could be read with some tone of snarkyness.  None
was intended.  Thanks to John for pointing that out.

> ...and...

> customers they believe are causing congestion.

Then the ISP should end the provider-consumer relationship.  This is not a
technical problem the IETF can solve, either.  Instead of sponsoring the
idea The IETF should run in the opposite direction of this PR nightmare.

> there has been an Internet.

Maybe I've just been plain lucky.  Comcast in my area (AT&T Broadband, TCI
prior to that) have been excellent.

Do we have any data to work with about this congestion?  (I feel like I'm
back to the subject of my paper.)  How bad? How prolonged?  And since the
ISPs control the product parameters -- the sizes of the shared pools of
bandwidth, the number of consumers who share it, the prices of admission,
and the size of the pipes between a subscriber and the shared pool -- does
the technical community generally accept that this as a business problem or
a technical problem?

Robb Topolski

---

From: Richard Bennett <[email-masked]>
Date: Sat, 07 Jun 2008 17:10:26 -0700

I think the point is that the Internet's traffic model only works if
the first-hop network handled most of the congestion and the core is
relatively uncongested. That's because congestion management mitigates
overload at the source, and the fewer hops the load travels before
back-pressure is applied, the more efficient the use of network
resources. Reading RFCs 896 and 970 and this remark by John Nagle on
Slashdot may help:

http://tech.slashdot.org/comments.pl?sid=497516&cid=22847764

RB

Robb Topolski wrote:

responses inlined --

On Sat, Jun 7, 2008 at 12:39 PM, John Leslie
<[email-masked]>
wrote:

Maybe I've just been plain lucky.  Comcast in my area (AT&T
Broadband, TCI prior to that) have been excellent.

Do we have any data to work with about this congestion?  (I feel like
I'm back to the subject of my paper.)  How bad? How prolonged?  And
since the ISPs control the product parameters -- the sizes of the
shared pools of bandwidth, the number of consumers who share it, the
prices of admission, and the size of the pipes between a subscriber and
the shared pool -- does the technical community generally accept that
this as a business problem or a technical problem?

Robb Topolski

--

Hillsboro, Oregon USA

---

From: Lars Eggert <[email-masked]>
Date: Mon, 9 Jun 2008 11:15:17 +0200

RFC3662?

---

From: "Stanislav Shalunov" <[email-masked]>
Date: Mon, 9 Jun 2008 02:23:42 -0700

See also http://qos.internet2.edu/wg/wg-documents/qbss-definition.txt

-- 
Stanislav Shalunov
http://shlang.com/

---

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 9 Jun 2008 16:58:34 -0400

And RFC 4594 (e.g. section 4.10) introduces the term 'Low-Priority Data'
-- which had been called Scavenger in the QBSS reference below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stanislav Shalunov
Sent: Monday, June 09, 2008 5:24 AM
To: Lars Eggert
Cc: [email-masked]
Subject: Re: [p2pi] Follow-Up from Comcast Presentation

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 9 Jun 2008 17:19:43 -0400

Then again, maybe it's not just luck.  ;-)  Maybe it is a combination of
(among other factors) (1) good network capacity management, (2) regular
course of business / ongoing network upgrades (often related to #1), (3)
one form of network management that has been effective in some way, and
(4) great local HFC network operations by our team in Oregon.  I am glad
that you describe your service as 'excellent' (even with the TCP RSTs
that have obviously been performed in your area).  I can't tell you how
much I look forward to the day when we implement the new network
management technique in Hillsboro, Oregon, and you can personally
confirm the absence of TCP RSTs in your P2P use.  :-)
 
Jason

	Robb Topolski