IP/MPLS Circuit Provisioning Software

[Gregory Urban]

Currently, our network uses ATM to provide approximately 1200 virtual
circuits to our subscriber base.  We use the ATM switch manufacturer's
management software (Marconi Service On Data) to manage both the ATM
switches and all of the virtual circuits (mostly SVCs) we have
provisioned.

 

We are in the process of migrating off of ATM and provisioning these
services as MPLS circuits (mostly pseudo-wire).  But we need a tool to
replace Service On Data, as configuring 1200 circuits manually on each
router/switch isn't going to cut it.  The network is primarily Juniper
Routers at the core and Cisco 3750 Metro switches at the edge.

 

Does anyone have any experience with a provisioning tool that can build
MPLS circuits in a multi-vendor network?  We're evaluating Dorado Red
Cell, but I'm not sold on it yet.

 

TIA.

 

Gregory Urban

Director, networkMaryland

www.networkMaryland.gov  

 

Re: houston.rr.com MX fubar?

[Suresh Ramasubramanian]

On Jan 13, 2008 9:55 PM, Tony Finch <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Jan 2008, Suresh Ramasubramanian wrote:
> >
> > One operationally better way to go seems to be Mark Delany's mx0dot
> > proposal, which started out as an internet draft, but seems to have
> > lost momentum .. the concept is sound though.
>
> Exim implements this convention.

Er, the concept is DNS related .. totally MTA independent.  Simply
declaring that there is no MX record in a way that stops fallback to
an A record.

Exim would check for such.  Other MTAs, even those that dont
explicitly check for it, would try to deliver email and fail
immediately, creating a 550 / NDN / whatever.

Basically -

> To indicate that a domain never accepts email, it advertises a solitary MX RR 
> with a RDATA section consisting of an arbitrary preference number 0, and a 
> dot terminated null string as the mail exchanger domain, to denote that there 
> exists no mail exchanger for a domain.
>
> The dot termination denotes that the null MX domain is considered to be 
> absolute, and not relative to the origin of the zone, the behavior of dot 
> termination and the formatting of this record is as described in STD13
>

--srs

Re: [Fwd: Unstable BGP Peerings?]

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Interesting, given that TTNet sits atop this ranking:

https://nssg.trendmicro.com/nrs/reports/rank.php?page=1

I wonder if this is somehow related? ;-)

- - ferg


- -- Sue Joiner <[EMAIL PROTECTED]> wrote:

Forwarding for Mohit Lad and Jonathan Park.

   -sue

Sue Joiner
Merit Network

-  Original Message 
Subject:Unstable BGP Peerings?
Date:   Sun, 13 Jan 2008 17:49:44 +
From:   ParkJonathan <[EMAIL PROTECTED]>
To: 
CC: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>



During our recent study on BGP routing instability, we found cases where
lots of routes changed from one subpath to another subpath, repeating this
kind of behavior over a few months . We do not know the cause of this
repeated instability, but suspect the BGP peering between routers in two
AS was unstable or had some problems and this caused routing changes seen
by many observation points.

Specifically, the peerings in question are

174 (Cogent) and 9121 (TTNet)
3257 (Tiscali) and 9121 (TTNet)
9304 (Hutchison) and 15412 (Flag Telecom)
1273 (Cable&Wireless)  4651 (Thai Gateway)
6762 (Seabone) and 7473 (Singapore Telecom)

For details of events and timings, please find a short summary on the
link below.
http://irl.cs.ucla.edu/pca/active-links.html

We would really appreciate if somebody from the ISPs involved in this
activity (or anybody who might know what happened) would contact us and
throw some light on the reasons for this behavior.

Thanks

Mohit Lad, Jonathan Park
UCLA

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFHiqUVq1pz9mNUZTMRAkVEAJ0Y4u5AYr/CiG65e3e+Y88HCQJGjQCg723O
P17FTAUFOw3Ms1KQW6v2+44=
=013x
-END PGP SIGNATURE-



--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: ISPs slowing P2P traffic...

[Joe Greco]

> > P2P based CDN's are a current buzzword; 

P2P based CDN's might be a current buzzword, but are nothing more than
P2P technology in a different cloak.  No new news here.

> This should prove to be interesting.   The Video CDN model will be a 
> threat to far more operators than P2P has been to the music industry.
> 
> Cable companies make significant revenue from video content (ok - that 
> was obvious).Since they are also IP Network operators they have a 
> vested interest in seeing that video CDN's  that bypass their primary 
> revenue stream fail.The ILEC's are building out fiber mostly so that 
> they can compete with the cable companies with a triple play solution.   
> I can't see them being particularly supportive of this either.  As a 
> wireless network operator I'm not terribly interested in helping 3rd 
> parties that cause issue on my network with upload traffic (rant away 
> about how were getting paid by the end user to carry this traffic...).

At the point where an IP network operator cannot comprehend (or, worse,
refuses to comprehend) that every bit received on the Internet must be
sourced from somewhere else, then I wish them the best of luck with the
legislated version of "network neutrality" that will almost certainly
eventually result from their shortsighted behaviour.

You do not get a free pass just because you're a wireless network
operator.  That you've chosen to model your network on something other
than a 1:1 ratio isn't anyone else's problem, and if it comes back to
haunt you, oh well.  It's nice that you can take advantage of the fact
that there are currently content-heavy and eyeball-heavy networks, but
to assume that it must stay that way is foolish.

It's always nice to maintain some particular model for your operations
that is beneficial to you.  It's clearly ideal to be able to rely on
overcommit in order to be able to provide the promises you've made to
customers, rather than relying on actual capacity.  However, this will
assume that there is no fundamental change in the way things work, which
is a bad assumption on the Internet.

This problem is NOTHING NEW, and in fact, shares some significant
parallels with the way Ma Bell used to bill out long distance vs local 
service, and then cried and whined about how they were being undercut
by competitive LD carriers.  They ... adapted.  Can you?  Will you?

And yes, I realize that this borders on unfair-to-the-(W)ISP, but if
you are incapable of considering and contemplating these sorts of
questions, then that's a bad thing.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

[Fwd: Unstable BGP Peerings?]

[Sue Joiner]

Forwarding for Mohit Lad and Jonathan Park.

  -sue

Sue Joiner
Merit Network

 Original Message 
Subject:Unstable BGP Peerings?
Date:   Sun, 13 Jan 2008 17:49:44 +
From:   ParkJonathan <[EMAIL PROTECTED]>
To: 
CC: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>



During our recent study on BGP routing instability, we found cases where
lots of routes changed from one subpath to another subpath, repeating this
kind of behavior over a few months . We do not know the cause of this
repeated instability, but suspect the BGP peering between routers in two
AS was unstable or had some problems and this caused routing changes seen
by many observation points.

Specifically, the peerings in question are

174 (Cogent) and 9121 (TTNet)
3257 (Tiscali) and 9121 (TTNet)
9304 (Hutchison) and 15412 (Flag Telecom)
1273 (Cable&Wireless)  4651 (Thai Gateway)
6762 (Seabone) and 7473 (Singapore Telecom)

For details of events and timings, please find a short summary on the
link below.
http://irl.cs.ucla.edu/pca/active-links.html

We would really appreciate if somebody from the ISPs involved in this
activity (or anybody who might know what happened) would contact us and
throw some light on the reasons for this behavior.

Thanks

Mohit Lad, Jonathan Park
UCLA


e벗 사귀기, 쪽지 보내기, 가젯 즐기기를 통해 전세계 친구들을 만나세요! 나
의 글로벌 인맥, Windows Live Space! 

Re: ISPs slowing P2P traffic...

[Mark Radabaugh]

Geo. wrote:




The vast majority of our last-mile connections are fixed wireless.   The
design of the system is essentially half-duplex with an adjustable 
ratio between download/upload traffic.


This in a nutshell is the problem, the ratio between upload and 
download should be 1:1 and if it were then there would be no problems. 
Folks need to stop pretending they aren't part of the internet. 
Setting a ratio where upload:download is not 1:1 makes you a leech. 
It's a cheat designed to allow technology companies to claim their 
devices provide more bandwidth than they actually do. Bandwidth is 2 
way, you should give as much as you get.


Making the last mile a 18x unbalanced pipe (ie 6mb down and 384K up) 
is what has created this problem, not file sharing, not running 
backups, not any of the things that require up speed. For the entire 
internet up speed must equal down speed or it can't work. You can't 
leech and expect everyone else to pay for your unbalanced approach.


Geo. 
Your back to the 'last mile access' problem.   Most Cable, DSL, and 
Wireless is asymmetric and for good reason - making efficient use of 
limited overall bandwidth and providing customers the high download 
speeds they demand.


You can posit that the Internet should be symmetric but it will take 
major financial and engineering investment to change that.   Given that 
there is no incentive for network operators to assist 3rd party CDN's by 
increasing upload speeds I don't see this happening in the near 
future.   I am not even remotely surprised that network operators would 
be interested in disrupting this traffic.


Mark

Re: ISPs slowing P2P traffic...

[Mark Radabaugh]

P2P based CDN's are a current buzzword; Verilan even has a white paper 
on it


https://www.verisign.com/cgi-bin/clearsales_cgi/leadgen.htm?form_id=9653&toc=e20050314159653020&ra=72.219.222.192&email= 




Password protected link.

I think we are going to see a lot more of this, and not just from "kids."

Regards
Marshall
This should prove to be interesting.   The Video CDN model will be a 
threat to far more operators than P2P has been to the music industry.


Cable companies make significant revenue from video content (ok - that 
was obvious).Since they are also IP Network operators they have a 
vested interest in seeing that video CDN's  that bypass their primary 
revenue stream fail.The ILEC's are building out fiber mostly so that 
they can compete with the cable companies with a triple play solution.   
I can't see them being particularly supportive of this either.  As a 
wireless network operator I'm not terribly interested in helping 3rd 
parties that cause issue on my network with upload traffic (rant away 
about how were getting paid by the end user to carry this traffic...).


Mark

RE: ISPs slowing P2P traffic...

[michael.dillon]

> I would be much happier creating a torrent server at the data 
> center level that customers could seed/upload from rather 
> than doing it over 
> the last mile.   I don't see this working from a legal 
> standpoint though.

Seriously, I would discuss this with some lawyers who have
experience in the Internet area before coming to a conclusion
on this. The law is as complex as the Internet itself.

In particular, there is a technical reason for setting up 
such torrent seeding servers in a data center and that 
technical reason is not that different from setting up
a web-caching server (either in or out) in a data center.
Or setting up a web server for customers in your data center.

As long as you process takedown notices for illegal torrents
in the same way that you process takedown notices for illegal
web content, you may be able to make this work.

Go to Google and read a half-dozen articles about "sideloading"
to compare it to what you want to do. In fact, sideload.com may
have done some of the initial legal legwork for you. It's worth
discussing this with a lawyer to find out the limits in which 
you can work and still be legal.

>From a technical point of view, if your Bittorrent protocol seeder
does not have a copy of the file on its harddrive, but pulls it
in from the customer's computer, you would only be caching the
file in RAM and there is some legal precedent going back into
the pre-Internet era that exempts such copies from legislation.

--Michael Dillon

Re: ISPs slowing P2P traffic...

[Marshall Eubanks]

On Jan 13, 2008, at 3:50 PM, Joe Greco wrote:



It may.  Some of those other things will, too.  I picked 1) and  
2) as

examples where things could actually get busy for long stretches of
time.


The wireless ISP business is a bit of a special case in this  
regard, where P2P traffic is especially nasty.


If I have ten customers uploading to a Web site (some photo  
sharing site, or Web-based email, say), each of whom is maxing out  
their connection, that's not a problem.


That is not in evidence.  In fact, quite the opposite...  given the  
scenario
previously described (1.5M tower backhaul, 256kbps customer CIR),  
it would
definitely be a problem.  The data doesn't become smaller simply  
because it

is Web traffic.

If I have one customer running Limewire or Kazaa or whatever P2P  
software all the cool kids are running these days, even if he's  
rate-limited himself to half his connection's maximum upload  
speec, that often IS a problem.


That is also not in evidence, as it is well within what the link  
should be

able to handle.


It's not the bandwidth, it's the number of packets being sent out.


Well, PPS can be a problem.  Certainly it is possible to come up with
hardware that is unable to handle the packets per second, and wifi can
be a bit problematic in this department, since there's such a wide
variation in the quality of equipment, and even with the best,  
performance
in the PPS arena isn't generally what I'd consider stellar.   
However, I'm
going to guess that there are online gaming and VoIP applications  
which are

just as stressful.  Anyone have a graph showing otherwise (preferably
packet size and PPS figures on a low speed DSL line, or something like
that?)

One customer, talking to twenty or fifty remote hosts at a time,  
can "kill" a wireless access point in some instances. All those  
little tiny packets


Um, I was under the impression that FastTrack was based on TCP...?   
I'm not
a file-sharer, so I could be horribly wrong.  But if it is based on  
TCP,
then one would tend to assume that actual P2P data transfers would  
appear
to be very similar to any other HTTP (or more generally, TCP)  
traffic - and
for transmitted data, the packets would be large.  I was actually  
under the

impression that this was one of the reasons that the DPI vendors were
successful at selling the D in DPI.

tie up the AP's radio time, and the other nine customers call and  
complain.


That would seem to be an implementation issue.  I don't hear WISP's  
crying
about gaming or VoIP traffic, so apparently those volumes of  
packets per
second are fine.  The much larger size of P2P data packets should  
mean that
the rate of possible PPS would be lower, and the number of  
individual remote
hosts should not be of particular significance, unless maybe you're  
trying

to implement your WISP on consumer grade hardware.

I'm not sure I see the problem.

One customer just downloading stuff, disabling all the upload  
features in their P2P client of choice, often causes exactly the  
same problem, as the kids tend to queue up 17 CDs worth of music  
then leave it running for a week. The software tries its darnedest  
to find each of those hundreds of different files, downloading  
little pieces of each of 'em from multiple servers.


Yeah, but "little pieces" still works out to fairly sizeable  
chunks, when
you look at it from the network point of view.  It isn't trying to  
download

a 600MB ISO with data packets that are only 64 bytes of content each.

We go out of our way to explain to every customer that P2P  
software isn't permitted on our network, and when we see it, we  
shut the customer off until that software is removed. It's not  
ideal, but given the limitations of wireless technology, it's a  
necessary compromise. I still have a job, so we must have a few  
customers who are alright with this limitation on their broadband  
service.


There's more to bandwidth than just bandwidth.


If so, there's also "Internet," "service," and "provider" in ISP.

P2P is "nasty" because it represents traffic that wasn't planned  
for or
allowed for in many business models, and because it is easy to  
perceive

that traffic as "unnecessary" or "illegitimate."

For now, you can get away with placing such a limit on your broadband
service, and you "still have a job," but there may well come a day  
when

some new killer service pops up.  Imagine, for example, TiVo deploying
a new set of video service offerings that bumped them back up into  
being

THE device of the year (don't think TiVo?  Maybe Apple, then...  who
knows?)  Downloads "interesting" content for local storage.   
Everyone's

buzzing about it.  The lucky 10% buy it.



P2P based CDN's are a current buzzword; Verilan even has a white  
paper on it


https://www.verisign.com/cgi-bin/clearsales_cgi/leadgen.htm? 
form_id=9653&toc=e20050314159653020&ra=72.219.222.192&email=


I think we are going to see a lot more of this, and not just 

Re: ISPs slowing P2P traffic...

[Mikael Abrahamsson]

On Sun, 13 Jan 2008, David E. Smith wrote:

It's not the bandwidth, it's the number of packets being sent out. One 
customer, talking to twenty or fifty remote hosts at a time, can "kill" 
a wireless access point in some instances. All those little tiny packets 
tie up the AP's radio time, and the other nine customers call and 
complain.


If it's concurrent tcp connections per customer you're worried about, then 
I guess you should aquire something that can actually enforce a limitation 
you want to impose.


Or if you want to protect yourself from customers going encrypted on you, 
I guess you can start to limit the concurrent number of servers they can 
talk to.


I can think of numerous problems with this approach though, so like other 
people here have suggested, you really need to look into your technical 
platform you use to produce your service as it's most likely is not going 
to work very far into the future. P2P isn't going to go away.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: ISPs slowing P2P traffic...

[Joe Greco]

> >It may.  Some of those other things will, too.  I picked 1) and 2) as
> >examples where things could actually get busy for long stretches of
> >time.
> 
> The wireless ISP business is a bit of a special case in this regard, where 
> P2P traffic is especially nasty.
> 
> If I have ten customers uploading to a Web site (some photo sharing site, or 
> Web-based email, say), each of whom is maxing out their connection, that's 
> not a problem.

That is not in evidence.  In fact, quite the opposite...  given the scenario
previously described (1.5M tower backhaul, 256kbps customer CIR), it would 
definitely be a problem.  The data doesn't become smaller simply because it
is Web traffic.

> If I have one customer running Limewire or Kazaa or whatever P2P software all 
> the cool kids are running these days, even if he's rate-limited himself to 
> half his connection's maximum upload speec, that often IS a problem.

That is also not in evidence, as it is well within what the link should be
able to handle.

> It's not the bandwidth, it's the number of packets being sent out.

Well, PPS can be a problem.  Certainly it is possible to come up with
hardware that is unable to handle the packets per second, and wifi can
be a bit problematic in this department, since there's such a wide
variation in the quality of equipment, and even with the best, performance
in the PPS arena isn't generally what I'd consider stellar.  However, I'm
going to guess that there are online gaming and VoIP applications which are
just as stressful.  Anyone have a graph showing otherwise (preferably
packet size and PPS figures on a low speed DSL line, or something like
that?)

> One customer, talking to twenty or fifty remote hosts at a time, can "kill" a 
> wireless access point in some instances. All those little tiny packets 

Um, I was under the impression that FastTrack was based on TCP...?  I'm not
a file-sharer, so I could be horribly wrong.  But if it is based on TCP,
then one would tend to assume that actual P2P data transfers would appear
to be very similar to any other HTTP (or more generally, TCP) traffic - and
for transmitted data, the packets would be large.  I was actually under the
impression that this was one of the reasons that the DPI vendors were
successful at selling the D in DPI.

> tie up the AP's radio time, and the other nine customers call and complain.

That would seem to be an implementation issue.  I don't hear WISP's crying
about gaming or VoIP traffic, so apparently those volumes of packets per
second are fine.  The much larger size of P2P data packets should mean that 
the rate of possible PPS would be lower, and the number of individual remote 
hosts should not be of particular significance, unless maybe you're trying 
to implement your WISP on consumer grade hardware.

I'm not sure I see the problem.

> One customer just downloading stuff, disabling all the upload features in 
> their P2P client of choice, often causes exactly the same problem, as the 
> kids tend to queue up 17 CDs worth of music then leave it running for a week. 
> The software tries its darnedest to find each of those hundreds of different 
> files, downloading little pieces of each of 'em from multiple servers. 

Yeah, but "little pieces" still works out to fairly sizeable chunks, when 
you look at it from the network point of view.  It isn't trying to download
a 600MB ISO with data packets that are only 64 bytes of content each.

> We go out of our way to explain to every customer that P2P software isn't 
> permitted on our network, and when we see it, we shut the customer off until 
> that software is removed. It's not ideal, but given the limitations of 
> wireless technology, it's a necessary compromise. I still have a job, so we 
> must have a few customers who are alright with this limitation on their 
> broadband service.
> 
> There's more to bandwidth than just bandwidth.

If so, there's also "Internet," "service," and "provider" in ISP.

P2P is "nasty" because it represents traffic that wasn't planned for or
allowed for in many business models, and because it is easy to perceive
that traffic as "unnecessary" or "illegitimate."

For now, you can get away with placing such a limit on your broadband
service, and you "still have a job," but there may well come a day when
some new killer service pops up.  Imagine, for example, TiVo deploying
a new set of video service offerings that bumped them back up into being
THE device of the year (don't think TiVo?  Maybe Apple, then...  who
knows?)  Downloads "interesting" content for local storage.  Everyone's
buzzing about it.  The lucky 10% buy it.

Now the question that will come back to you is, why can't your network
deliver what's been promised?

The point here is that there are people promising things they can't be
certain of delivering.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance 

Re: ISPs slowing P2P traffic...

[Mark Radabaugh]

I would be much happier creating a torrent server at the data center 
level that customers could seed/upload from rather than doing it over 
the last mile.   I don't see this working from a legal standpoint though.



Why not?  There's plenty of perfectly legal P2P content out there.


Hum... maybe there is an idea here.

I believe the bittorrent protocol rewards uploading users with faster 
downloading.   Moving the upload content to a more appropriate point on 
the network (a central torrent server) breaks this model.   How would a 
client get faster download speeds based on the uploads they made to a 
central server?To solve the inevitable legal issues there would also 
need to be a way to track how content ended up on the server as well.   
Are there any torrent clients that do this?


Mark

Re: ISPs slowing P2P traffic...

[Rubens Kuhl Jr.]

> The wireless ISP business is a bit of a special case in this regard, where 
> P2P traffic is especially nasty.
>
> It's not the bandwidth, it's the number of packets being sent out. One 
> customer, talking to twenty or fifty remote hosts at a time, can "kill" a 
> wireless access point in some instances. All those little tiny packets tie up 
> the AP's radio time, and the other nine customers call and complain.


Packets per second performance is specially low with Wi-Fi and Mesh
Wi-Fi, but not with all wireless technologies. WiMAX in the standards
side and some proprietary protocols have much better media access
mechanisms that can better withstand P2P and VoIP.


Rubens

Re: ISPs slowing P2P traffic...

[David E. Smith]

>It may.  Some of those other things will, too.  I picked 1) and 2) as
>examples where things could actually get busy for long stretches of
>time.

The wireless ISP business is a bit of a special case in this regard, where P2P 
traffic is especially nasty.

If I have ten customers uploading to a Web site (some photo sharing site, or 
Web-based email, say), each of whom is maxing out their connection, that's not 
a problem.

If I have one customer running Limewire or Kazaa or whatever P2P software all 
the cool kids are running these days, even if he's rate-limited himself to half 
his connection's maximum upload speec, that often IS a problem.

It's not the bandwidth, it's the number of packets being sent out. One 
customer, talking to twenty or fifty remote hosts at a time, can "kill" a 
wireless access point in some instances. All those little tiny packets tie up 
the AP's radio time, and the other nine customers call and complain.

One customer just downloading stuff, disabling all the upload features in their 
P2P client of choice, often causes exactly the same problem, as the kids tend 
to queue up 17 CDs worth of music then leave it running for a week. The 
software tries its darnedest to find each of those hundreds of different files, 
downloading little pieces of each of 'em from multiple servers. 

We go out of our way to explain to every customer that P2P software isn't 
permitted on our network, and when we see it, we shut the customer off until 
that software is removed. It's not ideal, but given the limitations of wireless 
technology, it's a necessary compromise. I still have a job, so we must have a 
few customers who are alright with this limitation on their broadband service.

There's more to bandwidth than just bandwidth.

David Smith
MVN.net

Re: ISPs slowing P2P traffic...

[Geo.]

The vast majority of our last-mile connections are fixed wireless.   The
design of the system is essentially half-duplex with an adjustable ratio 
between download/upload traffic.


This in a nutshell is the problem, the ratio between upload and download 
should be 1:1 and if it were then there would be no problems. Folks need to 
stop pretending they aren't part of the internet. Setting a ratio where 
upload:download is not 1:1 makes you a leech. It's a cheat designed to allow 
technology companies to claim their devices provide more bandwidth than they 
actually do. Bandwidth is 2 way, you should give as much as you get.


Making the last mile a 18x unbalanced pipe (ie 6mb down and 384K up) is what 
has created this problem, not file sharing, not running backups, not any of 
the things that require up speed. For the entire internet up speed must 
equal down speed or it can't work. You can't leech and expect everyone else 
to pay for your unbalanced approach.


Geo. 

Re: ISPs slowing P2P traffic...

[Joe Greco]

> Joe Greco wrote,
> > There are lots of things that could heavily stress your upload channel.
> > Things I've seen would include:
> >
> > 1) Sending a bunch of full-size pictures to all your friends and family,
> >which might not seem too bad until it's a gig worth of 8-megapixel 
> >photos and 30 recipients, and you send to each recipient separately,
> > 2) Having your corporate laptop get backed up to the company's backup
> >server,
> > 3) Many general-purpose VPN tasks (file copying, etc),
> > 4) Online gaming (capable of creating a vast PPS load, along with fairly
> >steady but low volumetraffic),
> >
> > etc.  P2P is only one example of things that could be stressful.
>   
> These things all happen - but they simply don't happen 24 hours a day, 7 
> days a week.   A P2P client often does.

It may.  Some of those other things will, too.  I picked 1) and 2) as
examples where things could actually get busy for long stretches of
time.

In this business, you have to realize that the average bandwidth use of
a residential Internet connection is going to grow with time, as new and
wonderful things are introduced.  In 1995, the average 14.4 modem speed
was perfectly fine for everyone's Internet needs.  Go try loading web
pages now on a 14.4 modem...  even web pages are bigger.

> 
> >
> > The questions boil down to things like:
> >
> > 1) Given that you unable to provide unlimited upstream bandwidth to your 
> >end users, what amount of upstream bandwidth /can/ you afford to
> >provide?
>   
> Again - it depends.   I could tell everyone they can have 56k upload 
> continuous and there would be no problem from a network standpoint - but 
> it would suck to be a customer with that restriction. 

If that's the reality, though, why not be honest about it?

> It's a balance between providing good service to most customers while 
> leaving us options.

The question is a lot more complex than that.  Even assuming that you have
unlimited bandwidth available to you at your main POP, you are likely to
be using RF to get to those remote tower sites, which may mean that there 
are some specific limits within your network, which in turn implies other
things.

> >> What Amplex won't do...
> >>
> >> Provide high burst speed if  you insist on running peer-to-peer file 
> >> sharing
> >> on a regular basis.  Occasional use is not a problem.   Peer-to-peer
> >> networks generate large amounts of upload traffic.  This continuous traffic
> >> reduces the bandwidth available to other customers - and Amplex will rate
> >> limit your connection to the minimum rated speed if we feel there is a
> >> problem. 
> >> 
> >
> > So, the way I would read this, as a customer, is that my P2P traffic would
> > most likely eventually wind up being limited to 256kbps up, unless I am on 
> > the business service, where it'd be 768kbps up.  
>
> Depends on your catching our attention.  As a 'smart' consumer you might 
> choose to set the upload limit on your torrent client to 200k and the 
> odds are pretty high we would never notice you.

... "today."  And since 200k is less than 256k, I would certainly expect
that to be true tomorrow, too.  However, it might not be, because your
network may not grow easily to accomodate more customers, and you may
perceive it as easier to go after the high bandwidth users, yes?

> For those who play nicely we don't restrict upload bandwidth but leave 
> it at the capacity of the equipment (somewhere between 768k and 1.5M).
> 
> Yep - that's a rather subjective criteria.   Sorry.
> 
> > This seems quite fair and
> > equitable.  It's clearly and unambiguously disclosed, it's still 
> > guaranteeing delivery of the minimum class of service being purchased, etc.
> >
> > If such an ISP were unable to meet the commitment that it's made to
> > customers, then there's a problem - and it isn't the customer's problem,
> > it's the ISP's.  This ISP has said "We guarantee our speeds will be as
> > good or better than we specify" - which is fairly clear.
> 
> We try to do the right thing - but taking the high road costs us when 
> our competitors don't.   I would like to think that consumers are smart 
> enough to see the difference but I'm becoming more and more jaded as 
> time goes on

You've picked a business where many customers aren't technically
sophisticated.  That doesn't necessarily make it right to rip them
off - even if your competitors do.

> > One solution is to stop accepting new customers where a tower is already
> > operating at a level which is effectively rendering it "full."
> 
> Unfortunately "full" is an ambiguous definition.Is it when:
> 
> a)  Number of Customers * 256k up = access point limit?
> b)  Number of Customers * 768k down = access point limit?
> c)  Peak upload traffic = access point limit?
> d)  Peak download traffic = access point limit?
> (e) Average ping times start to increase?
> 
> History shows (a) and (b) occur well before the AP is particularly 

Re: ISPs slowing P2P traffic...

[Mark Radabaugh]

Joe Greco wrote,

There are lots of things that could heavily stress your upload channel.
Things I've seen would include:

1) Sending a bunch of full-size pictures to all your friends and family,
   which might not seem too bad until it's a gig worth of 8-megapixel 
   photos and 30 recipients, and you send to each recipient separately,

2) Having your corporate laptop get backed up to the company's backup
   server,
3) Many general-purpose VPN tasks (file copying, etc),
4) Online gaming (capable of creating a vast PPS load, along with fairly
   steady but low volumetraffic),

etc.  P2P is only one example of things that could be stressful.
  
These things all happen - but they simply don't happen 24 hours a day, 7 
days a week.   A P2P client often does.





The questions boil down to things like:

1) Given that you unable to provide unlimited upstream bandwidth to your 
   end users, what amount of upstream bandwidth /can/ you afford to

   provide?
  
Again - it depends.   I could tell everyone they can have 56k upload 
continuous and there would be no problem from a network standpoint - but 
it would suck to be a customer with that restriction. 

It's a balance between providing good service to most customers while 
leaving us options.

What Amplex won't do...

Provide high burst speed if  you insist on running peer-to-peer file sharing
on a regular basis.  Occasional use is not a problem.   Peer-to-peer
networks generate large amounts of upload traffic.  This continuous traffic
reduces the bandwidth available to other customers - and Amplex will rate
limit your connection to the minimum rated speed if we feel there is a
problem. 



So, the way I would read this, as a customer, is that my P2P traffic would
most likely eventually wind up being limited to 256kbps up, unless I am on 
the business service, where it'd be 768kbps up.  
Depends on your catching our attention.  As a 'smart' consumer you might 
choose to set the upload limit on your torrent client to 200k and the 
odds are pretty high we would never notice you.


For those who play nicely we don't restrict upload bandwidth but leave 
it at the capacity of the equipment (somewhere between 768k and 1.5M).


Yep - that's a rather subjective criteria.   Sorry.


This seems quite fair and
equitable.  It's clearly and unambiguously disclosed, it's still 
guaranteeing delivery of the minimum class of service being purchased, etc.


If such an ISP were unable to meet the commitment that it's made to
customers, then there's a problem - and it isn't the customer's problem,
it's the ISP's.  This ISP has said "We guarantee our speeds will be as
good or better than we specify" - which is fairly clear.
  


We try to do the right thing - but taking the high road costs us when 
our competitors don't.   I would like to think that consumers are smart 
enough to see the difference but I'm becoming more and more jaded as 
time goes on



One solution is to stop accepting new customers where a tower is already
operating at a level which is effectively rendering it "full."
  


Unfortunately "full" is an ambiguous definition.Is it when:

a)  Number of Customers * 256k up = access point limit?
b)  Number of Customers * 768k down = access point limit?
c)  Peak upload traffic = access point limit?
d)  Peak download traffic = access point limit?
(e) Average ping times start to increase?

History shows (a) and (b) occur well before the AP is particularly 
loaded and would be wasteful of resources.  (c) occurs quickly with a 
relatively small number of P2P clients.  (e) Ping time variations occur 
slightly before (d) and is our usual signal to add capacity to a 
tower.   We have not yet run into the situation where we can not either 
reduce sector size (beamwidth, change polarity, add frequencies, etc.) 
but that day will come and P2P accelerates that process without 
contributing the revenue to pay for additional capacity.


As a small provider there is a much closer connect between revenue and 
cost.   100 'regular' customers pay the bills.   10 customers running 
P2P unchecked doesn't (and makes 90 others unhappy).


Were upload costs insignificant I wouldn't have a problem with P2P - but 
that unfortunately is not the case.


Mark

Re: ISPs slowing P2P traffic...

[Joe Greco]

> The vast majority of our last-mile connections are fixed wireless.   The 
> design of the system is essentially half-duplex with an adjustable ratio 
> between download/upload traffic.   PTP heavily stresses the upload 
> channel and left unchecked results in poor performance for other 
> customers. 

There are lots of things that could heavily stress your upload channel.
Things I've seen would include:

1) Sending a bunch of full-size pictures to all your friends and family,
   which might not seem too bad until it's a gig worth of 8-megapixel 
   photos and 30 recipients, and you send to each recipient separately,
2) Having your corporate laptop get backed up to the company's backup
   server,
3) Many general-purpose VPN tasks (file copying, etc),
4) Online gaming (capable of creating a vast PPS load, along with fairly
   steady but low volumetraffic),

etc.  P2P is only one example of things that could be stressful.

> Bandwidth quotas don't help much since it just moves the problem to the 
> 'start' of the quota time. 
> 
> Hard limits on upload bandwidth help considerably but do not solve the 
> problem since only a few dozen customers running a steady 256k upload 
> stream can saturate the channel.   We still need a way to shape the 
> upload traffic.
> 
> It's easy to say "put up more access points, sectors, etc.) but there 
> are constraints due to RF spectrum, tower space, etc.

Sure, okay, and you know, there's certainly some truth to that.  We know
that the cellular carriers and the wireless carriers have some significant
challenges in this department, and even the traditional DSL/cable providers
do too.

However, as a consumer, I expect that I'm buying an Internet connection.
What I'm buying that Internet connection for is, quite frankly, none of
your darn business.  I may want to use it for any of the items above.  I
may want to use my GPRS radio as emergency access to KVM-over-IP-reachable
servers.  I may want to use it to push videoconferencing from my desktop.
There are all these wonderful and wildly differing things that one can do
with IP connectivity.

> Unfortunately there are no easy answers here.   The network (at least 
> ours) is designed to provide broadband download speeds to rural 
> customers.   It's not designed and is not capable of being a CDN for the 
> rest of the world. 

I'd consider that a bad attitude, however.  Your network isn't being used
as "a CDN for the rest of the world," even if that's where the content 
might happen to be going.  That's an Ed Whitacre type attitude.  You have
a paying customer who has paid you to move packets for them.  Your network
is being used for heavy data transmission by one of your customers.  You
do not have a contract with "the rest of the world."  Unless you are
providing access to a walled garden, you have got to expect that your
customers are going to be sending and receiving data from "the rest of 
the world."  Your issue is mainly with the volume at which that is
happening, and shouldn't be with the destination or purpose of that 
traffic.

The questions boil down to things like:

1) Given that you unable to provide unlimited upstream bandwidth to your 
   end users, what amount of upstream bandwidth /can/ you afford to
   provide?

2) Are there any design flaws within your network that are making the
   overall problem worse?

3) What have you promised customers?

> I would be much happier creating a torrent server at the data center 
> level that customers could seed/upload from rather than doing it over 
> the last mile.   I don't see this working from a legal standpoint though.

Why not?  There's plenty of perfectly legal P2P content out there.

Anyways, let's look at a typical example.  There's a little wireless ISP
called Amplex down in Ohio, and looking at

http://www.amplex.net/wireless/wireless.htm

they say:

> Connection Speeds
> 
> Our residential service is rated at 384kbps download and 256kbps up,
> business service is 768kbps (equal down and up).  The network normally
> provides speeds well over those listed (up to 10 Mbps) but speed is
> dependant on network load and the quality of the wireless connection. 
> 
> Connection speed is nearly always faster than most DSL connections and
> equivalent (or faster) than many cable modems.  
> 
> Our competitors list maximum burst speeds with no guaranteed minimum speed.
> We guarantee our speeds will be as good or better than we specify in the
> service package you choose.. 

And then much further down:

> What Amplex won't do...
> 
> Provide high burst speed if  you insist on running peer-to-peer file sharing
> on a regular basis.  Occasional use is not a problem.   Peer-to-peer
> networks generate large amounts of upload traffic.  This continuous traffic
> reduces the bandwidth available to other customers - and Amplex will rate
> limit your connection to the minimum rated speed if we feel there is a
> problem. 

So, the way I would read this, as a customer, is that my

Re: houston.rr.com MX fubar?

[Tony Finch]

On Sun, 13 Jan 2008, Suresh Ramasubramanian wrote:
>
> One operationally better way to go seems to be Mark Delany's mx0dot
> proposal, which started out as an internet draft, but seems to have
> lost momentum .. the concept is sound though.

Exim implements this convention.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
HEBRIDES: CYCLONIC 5 TO 7, BUT GALE 8 OR SEVERE GALE 9 IN NORTH AND WEST.
ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD.

Re: ISPs slowing P2P traffic...

[Mark Radabaugh]

The vast majority of our last-mile connections are fixed wireless.   The 
design of the system is essentially half-duplex with an adjustable ratio 
between download/upload traffic.   PTP heavily stresses the upload 
channel and left unchecked results in poor performance for other 
customers. 

Bandwidth quotas don't help much since it just moves the problem to the 
'start' of the quota time. 

Hard limits on upload bandwidth help considerably but do not solve the 
problem since only a few dozen customers running a steady 256k upload 
stream can saturate the channel.   We still need a way to shape the 
upload traffic.


It's easy to say "put up more access points, sectors, etc.) but there 
are constraints due to RF spectrum, tower space, etc.


Unfortunately there are no easy answers here.   The network (at least 
ours) is designed to provide broadband download speeds to rural 
customers.   It's not designed and is not capable of being a CDN for the 
rest of the world. 

I would be much happier creating a torrent server at the data center 
level that customers could seed/upload from rather than doing it over 
the last mile.   I don't see this working from a legal standpoint though.


--

Mark Radabaugh
Amplex
419.837.5015 x21
[EMAIL PROTECTED]