- NANOG - lists.nanog.org

RE: ISPs slowing P2P traffic...
by Frank Bulk - iNAME 10 Jan '08

10 Jan '08

I'm not aware of any modern cable modems that operate at 10 Mbps. Not that they couldn't set it at that speed, but AFAIK, they're all 10/100 ports. Frank -----Original Message----- From: Blake Pfankuch [mailto:epic59@shenrons-house.com] Sent: Wednesday, January 09, 2008 9:47 PM To: frnkblk(a)iname.com; joe(a)oregon.uoregon.edu; jared(a)puck.nether.net; nanog(a)merit.edu Subject: RE: ISPs slowing P2P traffic... What about Comcast selling their new speed burst thing that allows up to 12 mbit, but also providing modems with a 10mbit Ethernet port. They have been doing that around here for quite a while... -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Frank Bulk - iNAME Sent: Wednesday, January 09, 2008 8:12 PM To: joe(a)oregon.uoregon.edu; jared(a)puck.nether.net; nanog(a)merit.edu Subject: RE: ISPs slowing P2P traffic... Without being totally conspiratorial, do you think the network engineers at these service providers know that that their residential subscribers' PCs and links aren't tuned for high speeds, and so can feel fairly confident in selling these speeds knowing they won't be used? Frank -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Joe St Sauver Sent: Wednesday, January 09, 2008 4:15 PM To: jared(a)puck.nether.net Cc: nanog(a)merit.edu Subject: Re: ISPs slowing P2P traffic... Jared mentioned: # We'll see what happens, and how the 160Mb/s DOCSIS 3.0 connections #and infrastructure to support it pan out on the comcast side.. There may be comparatively little difference from what you see today, largely because most hosts still have stacks which are poorly tuned by default, or host throughput is limited by some other device in the path (such as a broadband "router") which acts by default as the constricting link in the chain, or the application itself isn't written to take full advantage of higher speed wide area connections. Depending on your point of view, all those poorly tuned hosts are either a incredible PITA, or the only thing that's keeping the boat above water. If you believe the latter point of view, tuning guides such as http://www.psc.edu/networking/projects/tcptune/ and diagnostic tools like NDT (e.g., see http://miranda.ctd.anl.gov:7123/ ) are incredibly seditious resources. :-) Regards, Joe St Sauver (joe(a)oregon.uoregon.edu) Disclaimer: all opinions strictly my own.

2 1

Re: ISPs slowing P2P traffic...
by Joe St Sauver 10 Jan '08

10 Jan '08

Jared mentioned: # We'll see what happens, and how the 160Mb/s DOCSIS 3.0 connections #and infrastructure to support it pan out on the comcast side.. There may be comparatively little difference from what you see today, largely because most hosts still have stacks which are poorly tuned by default, or host throughput is limited by some other device in the path (such as a broadband "router") which acts by default as the constricting link in the chain, or the application itself isn't written to take full advantage of higher speed wide area connections. Depending on your point of view, all those poorly tuned hosts are either a incredible PITA, or the only thing that's keeping the boat above water. If you believe the latter point of view, tuning guides such as http://www.psc.edu/networking/projects/tcptune/ and diagnostic tools like NDT (e.g., see http://miranda.ctd.anl.gov:7123/ ) are incredibly seditious resources. :-) Regards, Joe St Sauver (joe(a)oregon.uoregon.edu) Disclaimer: all opinions strictly my own.

2 1

NANOG 42 Draft Agenda Announcement
by Todd Underwood 10 Jan '08

10 Jan '08

* puts Program Committee Chair hat on The NANOG Program Committee is happy to announce that a draft agenda is available for NANOG 42 to be held February 17-20 in San Jose, California. We were extremely pleased with the quality and quantity of submissions this time and will unfortunately have to turn down a number of recent submissions due to lack of space in the agenda. We're happy to announce that our Keynote will be given by Tom Killalea, VP of Technology at Amazon.com, along with Dan Cohn, Principle Network Engineer at Amazon.com. If you are a submitter and have not heard from the Program Committee regarding your submission, please contact me. Dates to be aware of: January 17: Early registration discount ends. If you plan to attend NANOG 42, just register now and get it out of the way already! :-) January 17: Lighting Talk registration opens. January 28: Hotel room block closes. In the past hotel rooms have occassionally run out before then. Again, just look at how great this agenda is and register already. Both tasks can be accomplished by links at http://www.nanog.org/ [The draft agenda follows. Caveats: speakers, topics and times subject to change, errors are my fault, many talks are concurrent, void where prohibited, etc.)] --------------------------------------------------------------------------------------------------- Sunday, February 17 --------------------------------------------------------------------------------------------------- Time Topic Presenter ---------------- ---------------------------------------------- ----------------------------------- 2:00pm - 3:30pm BGP Troubleshooting Techniques, Pt. 1 Philip Smith, Cisco Systems You Can Teach Problem Solving and Should Elizabeth Zwicky L2 Attacks & Mitigation Techniques Yusuf Bahaiji, Cisco Systems 3:30pm - 4:00pm Break & PGP Key Signing 4:00pm - 5:30pm BGP Troubleshooting Techniques, Pt. 2 Philip Smith, Cisco Systems Network Core Infrastructure, Best Practices Yusuf Bahaiji, Cisco Systems Security BoF Danny McPherson, Arbor Networks 5:30pm - 6:30pm NANOG Community Meeting --------------------------------------------------------------------------------------------------- Monday, February 18 --------------------------------------------------------------------------------------------------- Time Topic Presenter ---------------- ---------------------------------------------- ----------------------------------- 9:00 - 10:00 Newcomer's Breakfast Ren Provo, Comcast Continental Breakfast, access to meeting rooms, and network access Sponsors: (pending) 10:00 - 10:30 Opening Remarks Todd Underwood, Renesys John Savageau, CRG West 10:30 - 11:30 Keynote Presentation Tom Killalea and Dan Cohn, Amazon 11:30 - noon Break & PGP Key Signing Noon - 12:30pm Can ISP's and P2P Work Together Laird Popkin, Pando Networks Doug Pasko, Verizon 12:30pm - 1:00pm (pending) 1:00pm - 2:00pm Lunch 2:00pm - 3:30pm Panel: Green Data Centers Moderator: Martin Levy, Tier 1 Research 3:30pm - 4:00pm Break & PGP Key Signing 4:00pm - 5:30pm IX Operators BoF Moderator: Mike Hughes, LINX Small Operator Lessons Learned Pete Templin, Textlink 5:30pm - 7:30pm Bear & Gear Sponsors: (pending) --------------------------------------------------------------------------------------------------- Tuesday, February 19 --------------------------------------------------------------------------------------------------- Time Topic Presenter ---------------- ---------------------------------------------- ----------------------------------- 9:00 - 10:00 Continental Breakfast, access to meeting rooms, and network access 10:00 - 10:30 Lightning Talks ***The window for submissions opens 17-Jan-08*** 10:30 - 11:00 Aftershocks from the Taiwan Earthquakes: Shaking up Internet transit in Asia Martin A. Brownn, Renesys Corporation 11:00 - 11:30 100G: Standards Track Update Greg Hankins, Force 10 11:30 - noon Break & PGP Key Signing Noon - 1pm Panel: 100G Forwarding Achitecture Challenges Ted Seely, Sprint and Igor Gashinsky, Yahoo, Moderators 1:00pm - 2:00pm Lunch 2:00pm - 2:30pm Analysis of PTR Queries for IPv4 Addresses Reserved for Future Allocation Leo Vegoda, IANA (ICANN) 2:30pm - 3:00pm A Simple and Efficient 0(50msec) Resilience Technology for IPTV Dino Farinacci, Cisco Systems Clarence Filsfils, Cisco Systems 3:00pm - 3:30pm Graceful Restart and/or Non-Stop Routing with Stateful Switchover and Non-Stop Forwarding Ken Weissner, Cisco Systems 3:30pm - 4:00pm Break & PGP Key Signing 4:00pm - 5:30pm Peering BoF Bill Norton, Equinix Speaker: Efficient Technique for Enforcing Internet Peering Policies, David J. Smith, Cisco Systems Introduction to IPv6 Philip Smith, Cisco Systems 6:00pm - 8pm CRG Hosted Reception, offsite --------------------------------------------------------------------------------------------------- Wednesday, February 20 --------------------------------------------------------------------------------------------------- Time Topic Presenter ---------------- ---------------------------------------------- ----------------------------------- 8:30 - 9:30 Continental Breakfast, access to meeting rooms, and network access 9:30 - 10:00 Lightning Talks The window for submissions opens 17-Jan-08 10:00 - 10:30 (pending) 10:30 - 11:00 Break & PGP Key Signing 11:00 - 11:30 10G Pluggable Technology Richard Steenbergen, nLayer Communications 11:30 - 12:30 Future Note Surprise Speaker 12:30pm Closing Remarks Todd Underwood, Renesys Corporation -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation todd(a)renesys.com http://www.renesys.com/blog

1 0

RE: ISPs slowing P2P traffic...
by Joe St Sauver 09 Jan '08

09 Jan '08

Deepak mentioned: #However, my question is simply.. for ISPs promising broadband service. #Isn't it simpler to just announce a bandwidth quota/cap that your "good" #users won't hit and your bad ones will? Quotas may not always control the behavior of concern. As a hypothetical example, assume customers get 10 gigabytes worth of traffic per month. That traffic could be more-or-less uniformly distributed across all thirty days, but it is more likely that there will be some heavy usage days and light usage days, and some busy times and some slow times. Shaping or rate limiting traffic will shave the peak load during high demand days (which is almost always the real issue), while quota-based systems typically will not. Quota systems can also lead to weird usage artifacts. For example, assume that users can track how much of their quota they've used -- as you get to the end of each period, people may be faced with "use it or lose it" situations, leading to end-of-period spikes in usage. Quotas (at least in higher education contexts) can also lead to things like account sharing ("Hey, I'm out of 'credits' for this month -- you never use yours, so can I login using your account?" "Sure..." -- even if acceptable use policies prohibit that sort of thing) And then what do you do with users who reach their quota? Slow them down? Charge them more? Turn them off? All of those options are possible, but each comes with what can be its own hellish pain. And finally, manipulating all types of total traffic could also be bad if customers have a third party VoIP service running, and you block/throttle/other wise mess with untouchable voice service traffic when they need to make a 911 call or whatever. #Operationally, why not just lash a few additional 10GE cross-connects #and let these *paying customers* communicate as they will? I think the bottleneck is usually closer to the edge... Part of the issue is that consumer connections are often priced predicated on a relatively light usage model, and an assumption that much of that traffic may may be amenable to "tricks" (such as passive caching, or content served from local Akamai stacks, etc. -- although this is certainly less of an issue than it once was). Replace that model with one where consumers actually USE the entire connection they've purchased, rather than just some small statistically multiplexed fraction thereof, and make all traffic encrypted/opaque (and thus unavailable for potential "optimized delivery") and the default pricing model can break. You then have a choice to make: -- cover those increased costs (all associated with a relatively small number of users living in the tail of the consumption distribution) by increasing the price of the service for everyone (hard in a highly competitive market), or -- deal with just that comparative handful of users who don't fit the presumptive model (shape their traffic, encourage them to buy from your competitor, decline to renew their contract, whatever). The later is probably easier than the former. #I don't see how Operators could possibly debug connection/throughput #problems when increasingly draconian methods are used to manage traffic #flows with seemingly random behaviors. This seems a lot like the #evil-transparent caching we were concerned about years ago. Middleboxes can indeed make things a mess, but at least in some environments (e.g., higher ed residential networks), they've become pretty routine. Network transparency should be the goal, but operational transparency (e.g., telling people what you're doing to their traffic) may be an acceptable alternative in some circumstances. #What can be done operationally? Tiered service is probably the cleanest option: cheap "normal" service with shaping and other middlebox gunk for price sensitive populations with modest needs, and premium clear pipe service where the price reflects the assumption that 100% of the capacity provisioned will be used. Sort of like what many folks already do by offering "residential" and "commercial" grade service options, I guess... #For legitimate applications: # #Encouraging "encryption" of more protocols is an interesting way to #discourage this kind of shaping. Except encryption isn't enough. Even if I can't see the contents of packets, I can still do traffic analysis on the ASNs or FQDNs or IPs involved, the rate and number of packets transfered, the number of concurrent open sessions open to a given address of interest, etc. Encrypted P2P traffic over port 443 doesn't look the same as encrypted normal web traffic. :-) Unless you have an encrypted pipe that's *always* up and always *full* (padding lulls in real traffic with random filler sonets or whatever), and that connection is only exchanging traffic with one and only one remote destination, traffic analysis will almost always yield interesting insights, even if the body of the traffic is inaccessible. #Using IPv6 based IPs instead of ports would also help by obfuscating #protocol and behavior. Even IP rotation through /64s (cough 1 IP per #half-connection anyone). Some traffic also stands out simply because only "interesting people" exhibit the behavior in question. :-) That could be port hopping, or nailing up a constantly full encrypted connection that only talks to one other host. :-) #My caffeine hasn't hit, so I can't think of anything else. Is this #something the market will address by itself? I think so. At some point there's sufficient capacity everywhere, edge and core, that (a) there's no pressing operational need to shape traffic, and (b) the shaping devices available for the high capacity circuits are prohibitively expensive. That's part of the discussion I offered in "Capacity Planning and System and Network Security," a talk I did for the April '07 Internet2 Member Meeting, see http://www.uoregon.edu/~joe/i2-cap-plan/internet2-capacity-planning.ppt (or .pdf) at slides 44-45 or so. I'd also note that if end user hosts are comparatively clean and under control, traffic from a few "outlier" users is a lot easier to absorb than if you're infested with zombied boxes. In some cases, those bumps in the wire may not be targeting P2P traffic, but rather artifacts associated with botted hosts which are running excessively hot. Regards, Joe St Sauver (joe(a)oregon.uoregon.edu) Disclaimer: all opinions strictly my own.

1 0

Temperature Issues at Equinix Ashburn
by Deepak Jain 09 Jan '08

09 Jan '08

We've just seen equipment @ Equinix Ashburn spike +3C in a 5 minute window. Our input temps are now over 90degrees F. Is anyone else seeing similar issues (while we wait for EQIX to respond).. Thanks in advance, DJ

1 0

Using x.x.x.0 and x.x.x.255 host addresses in supernets.
by Joshman at joshman dot com 09 Jan '08

09 Jan '08

Hello all, As a general rule, is it best practice to assign x.x.x.0 and x.x.x.255 as host addresses on /23 and larger? I realize that technically they are valid addresses, but does anyone assign a node or server which is a member of a /22 with a x.x.x.0 and x.x.x.255? Is it just a manner of preference on whether or not to use them, or are there functional reasons you shouldn't; either with rfc 1918 addresses or public addresses. Thanks in advance, J --------------------------------- Never miss a thing. Make Yahoo your homepage.

9 12

IPv6 Reality Check [Was: Re: IPv6 connectivity mandates?]
by Paul Ferguson 09 Jan '08

09 Jan '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Valdis.Kletnieks(a)vt.edu wrote: >On Mon, 07 Jan 2008 14:58:27 EST, "Justin M. Streiner" said: >> Has anyone seen any indication that, given the US government's push to >> deploy IPv6, they will start (or perhaps they've started already?) >> writing mandates for applicant networks to have IPv6 connectivity into >> the >> requirements for federally funded grants? > >I haven't seen any. But we've been doing IPv6 for so long that it >wouldn't make a notice in our network group - people would just check it off as "BTDT", perhaps after calling our helpdesk and asking "Do we have it" and being told "Yes". > As with most Internet-related issues, the "market" will indeed decide. It amazes me how many times we revisit this issue. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHhGh+q1pz9mNUZTMRAnM9AKDjm8KzlJSEA7C7mOOcSSY0AEIg1QCfbax7 modWuSZPtckh6auU5jztER4= =iLJ+ -----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/ Please note: message attached

1 0

IPv6 connectivity mandates?
by Justin M. Streiner 09 Jan '08

09 Jan '08

Given all of the discussion about IPv6 on this last over the past several weeks, I figured I'd chum the waters a bit more :) This is mainly for people working in colleges and universities, but could apply to ISP/NSPs as well. Has anyone seen any indication that, given the US government's push to deploy IPv6, they will start (or perhaps they've started already?) writing mandates for applicant networks to have IPv6 connectivity into the requirements for federally funded grants? Is anyone seeing anything similar outside of the United States? Thanks jms

4 3

can the memory technology save the routing table size scalability problem?
by yangyang. wang 09 Jan '08

09 Jan '08

As we known, the DFZ RIB size expand rapidly. It may be resolved via router architecture improvement, such as adding memory chips or compressing RIB. or via changing routing and addressing scheme, which one will be the long-term essential approach?

3 2

Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
by Scott Weeks 09 Jan '08

09 Jan '08

--- rs(a)seastrom.com wrote: "Wayne E. Bouchard" <web(a)typo.org> writes: > So my oppinion is don't hesistate to use it until you find a real, > reproducible problem. Tell that to your call center manager. :-) ------------------------------------------ I've been using them for several years and no problems. We assign about a /15s worth of DHCP in /23s and use the middle .255 and .0 with zero calls of trouble. The first and last .0 and .255 in the /23 aren't used due to DHCP software silliness. scott

1 0