Re: SixXS Contact
Subject: Re: SixXS Contact Date: Thu, Jun 27, 2013 at 09:43:19PM +0200 Quoting Måns Nilsson (mansa...@besserwisser.org): Personally, even though I'm on the same IRC channel as one of the admins and could have all support I want, I went with HE. Zero trouble. Excellent service. I'm peering with them at work, as does my colo provider, så have great connectivity. And, in v6, renumbering is easy (RIGHT? ;) so swapping providers is no pain. Now, Owen, where's my T-shirt? ;-) Apparently I'm not on the same IRC channel as an admin anymore: Just let me state that the day after I quit working with SIXXS I got myself a HE tunnel -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 The FALAFEL SANDWICH lands on my HEAD and I become a VEGETARIAN ... signature.asc Description: Digital signature
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 29 Jun, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 456943 Prefixes after maximum aggregation: 186069 Deaggregation factor: 2.46 Unique aggregates announced to Internet: 227072 Total ASes present in the Internet Routing Table: 44373 Prefixes per ASN: 10.30 Origin-only ASes present in the Internet Routing Table: 34730 Origin ASes announcing only one prefix: 16155 Transit ASes present in the Internet Routing Table:5896 Transit-only ASes present in the Internet Routing Table:144 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 30 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 1668 Unregistered ASNs in the Routing Table: 758 Number of 32-bit ASNs allocated by the RIRs: 4834 Number of 32-bit ASNs visible in the Routing Table:3747 Prefixes from 32-bit ASNs in the Routing Table: 10990 Special use prefixes present in the Routing Table: 24 Prefixes being announced from unallocated address space:215 Number of addresses announced to Internet: 2625956140 Equivalent to 156 /8s, 132 /16s and 233 /24s Percentage of available address space announced: 70.9 Percentage of allocated address space announced: 70.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.7 Total number of prefixes smaller than registry allocations: 160087 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 109760 Total APNIC prefixes after maximum aggregation: 33678 APNIC Deaggregation factor:3.26 Prefixes being announced from the APNIC address blocks: 111592 Unique aggregates announced from the APNIC address blocks:45689 APNIC Region origin ASes present in the Internet Routing Table:4852 APNIC Prefixes per ASN: 23.00 APNIC Region origin ASes announcing only one prefix: 1215 APNIC Region transit ASes present in the Internet Routing Table:823 Average APNIC Region AS path length visible:4.8 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table:589 Number of APNIC addresses announced to Internet: 725314528 Equivalent to 43 /8s, 59 /16s and 107 /24s Percentage of available APNIC address space announced: 84.8 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:158854 Total ARIN prefixes after maximum aggregation:80348 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 159485 Unique aggregates announced from the ARIN address blocks: 74154 ARIN Region origin ASes present in the Internet Routing Table:15753 ARIN Prefixes per ASN:10.12 ARIN Region origin
We Are Watching You act to regulate consumer-watching devices.
About 30 years ago, when I first got involved with the Net (Usenet; thanks to USF and Spaf for the link, and Larry Strickland at SPJC for servers), one of the topics that everyone loved to rant about were supposed plans from the Neilsen Companies to put cameras on set top boxes and use them to get better data about how many people were watching TV. There was the expected public meltdown, as the word got 'round -- even given how impractical it would have been to implement with that day's tech -- and I was, frankly surprised that it didn't recur when Microsoft started putting cameras atop videogame consoles, in our much better connected world. In light of the Snowden fracas, it has now, finally, recurred: http://broadcastengineering.com/regulation/we-are-watching-you-act-introduced-regulate-privacy-home This is another example, I think, of a thing that only a very small number of people have thought proactively about over the years, but that I think network engineering people ought to be at the forefront of that group: I call it capability creep, by analogy to scope creep; it's the situation where because of changes in technologies only peripherally related to your own, yours suddenly acquires previously unexpected capabilities, for either good or evil. Ours -- high speed, pervasive, networking -- is probably the most common enabling technology which has this effect, and while we can't exactly just shut the routers off and go home, and while people spend a whole lot of time ignoring us on such topics (I can't count the toldjaso's from the last 3 decades), I still think it's a topic we ought to focus purposeful thinking on as we go about our lives of planning and executing the next generation of networks. And the next. And the next. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Service provider T1/PPP question
On Fri, 28 Jun 2013 00:07:45 -0400, Mike mike-na...@tiedyenetworks.com wrote: I am wanting to offer a broadband over T1 service and have the ... s/broadband/internet/ A T1 is miles away from broadband these days. Having done this with Cisco gear (*years* ago), you want to avoid MLPPP whenever possible. We did CEF per-packet when the CPE end was also Cisco; it worked perfectly with none of the restrictions or bugs. --Ricky
RE: Service provider T1/PPP question
-Original Message- From: Ricky Beam [mailto:jfb...@gmail.com] Sent: Friday, June 28, 2013 2:45 PM To: NANOG list; Mike Subject: Re: Service provider T1/PPP question On Fri, 28 Jun 2013 00:07:45 -0400, Mike mike-na...@tiedyenetworks.com wrote: I am wanting to offer a broadband over T1 service and have the ... s/broadband/internet/ A T1 is miles away from broadband these days. Having done this with Cisco gear (*years* ago), you want to avoid MLPPP whenever possible. We did CEF per-packet when the CPE end was also Cisco; it worked perfectly with none of the restrictions or bugs. --Ricky I think this post seems like a flashback. I would not consider a T-1 to really be broadband anymore and it is pretty much limited to a business environment the way tariffs work. As far as MLPPP, it seems to be pretty stable now where you need multiple bonded T-1s. We have a few sites running MLPPP with Sprint on Juniper and Cisco gear and have not had an issue with it. It is definitely not my preference for business connectivity anymore. We tend to look for Ethernet service which is way cheaper per mb than T-1 and requires less expensive terminal equipment in most cases. T-1s are the business solution where you need dedicated MPLS connectivity and fiber transport is not available. DSL or Internet VPN are OK but somewhat less stable for business class private network solutions. If it is internet connectivity they want you will get beaten up by the cable companies that can outrun and outprice you across the board. You will also have a heck of a time competing with incumbent and competitive telecoms in T-1s that have central offices or collocations in central offices. The economics just don't work if you don't have direct access to the cable plant. Maybe up until the telecom act but not now. How do you intend to get those T-1s back to you or are you a CLEC? Steven Naslund
Google's QUIC
http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 Sorry if this is a little more on the dev side, and less on the ops side but since it's Google, it will almost certainly affect the ops side eventually. My first reaction to this was why not SCTP, but apparently they think that middle boxen/firewalls make it problematic. That may be, but UDP based port filtering is probably not far behind on the flaky front. The second justification was TLS layering inefficiencies. That definitely has my sympathies as TLS (especially cert exchange) is bloated and the way that it was grafted onto TCP wasn't exactly the most elegant. Interestingly enough, their main justification wasn't a security concern so much as helpful middle boxen getting their filthy mitts on the traffic and screwing it up. The last thing that occurs to me reading their FAQ is that they are seemingly trying to send data with 0 round trips. That is, SYN, data, data, data... That really makes me wonder about security/dos considerations. As in, it sounds too good to be true. But maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm. Other comments or clue? Mike
Re: Google's QUIC
My first question is, how are they going to keep themselves from congesting links? On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas m...@mtcc.com wrote: http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 Sorry if this is a little more on the dev side, and less on the ops side but since it's Google, it will almost certainly affect the ops side eventually. My first reaction to this was why not SCTP, but apparently they think that middle boxen/firewalls make it problematic. That may be, but UDP based port filtering is probably not far behind on the flaky front. The second justification was TLS layering inefficiencies. That definitely has my sympathies as TLS (especially cert exchange) is bloated and the way that it was grafted onto TCP wasn't exactly the most elegant. Interestingly enough, their main justification wasn't a security concern so much as helpful middle boxen getting their filthy mitts on the traffic and screwing it up. The last thing that occurs to me reading their FAQ is that they are seemingly trying to send data with 0 round trips. That is, SYN, data, data, data... That really makes me wonder about security/dos considerations. As in, it sounds too good to be true. But maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm. Other comments or clue? Mike
Re: Google's QUIC
On 06/28/2013 01:16 PM, Josh Hoppes wrote: My first question is, how are they going to keep themselves from congesting links? The FAQ claims they're paying attention to that, but I haven't read the details. I sure hope they grok that not understanding Van Jacobson dooms you to repeat it. https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/preview?sle=true#heading=h.h3jsxme7rovm Mike On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas m...@mtcc.com wrote: http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 Sorry if this is a little more on the dev side, and less on the ops side but since it's Google, it will almost certainly affect the ops side eventually. My first reaction to this was why not SCTP, but apparently they think that middle boxen/firewalls make it problematic. That may be, but UDP based port filtering is probably not far behind on the flaky front. The second justification was TLS layering inefficiencies. That definitely has my sympathies as TLS (especially cert exchange) is bloated and the way that it was grafted onto TCP wasn't exactly the most elegant. Interestingly enough, their main justification wasn't a security concern so much as helpful middle boxen getting their filthy mitts on the traffic and screwing it up. The last thing that occurs to me reading their FAQ is that they are seemingly trying to send data with 0 round trips. That is, SYN, data, data, data... That really makes me wonder about security/dos considerations. As in, it sounds too good to be true. But maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm. Other comments or clue? Mike
Re: Google's QUIC
On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas m...@mtcc.com wrote: http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 Sorry if this is a little more on the dev side, and less on the ops side but since it's Google, it will almost certainly affect the ops side eventually. My first reaction to this was why not SCTP, but apparently they think that middle boxen/firewalls make it problematic. That may be, but UDP based port filtering is probably not far behind on the flaky front. Sounds like a UDP replacement. If this is true, then OS-level support will be needed. If they are on this, then it's the perfect opportunity to fix some other problems with the Internet in general. My reaction is: why, oh why, repeat the same mistake of merging everything on the transport layer and let the benefits be protocol-specific instead of separating the transport from session. I mean, why not let redundancy and multipath stay on the transport layer through some kind of end-user transport (like the Host Identification Protocol, RFC 5201) and let a simpler TCP and UDP live on top of that, on the session layer. Streamline the protocols and separate their functionality. It's easier than it sounds. -- Octavio.
Re: Google's QUIC
On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas m...@mtcc.com wrote: http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 Sounds like a UDP replacement. If this is true, then OS-level support will be needed. If they are on this, then it's the perfect opportunity to fix some other problems with the Internet in general. I'm no genius, but doesn't the article say it's UDP? (in the name of the protocol even) -chris
Re: Google's QUIC
On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: Sounds like a UDP replacement. If this is true, then OS-level support will be needed. If they are on this, then it's the perfect opportunity to fix some other problems with the Internet in general. I'm no genius, but doesn't the article say it's UDP? (in the name of the protocol even) I was trying to emphasize replacement, not UDP. This is, that works on the same layer, that requires OS-level modifications, as opposed to a protocol that could be similar to UDP but work on the application layer. My point was that all that work could be focused on a *really* good transport (even with end-user multihoming without bloating the routing table), and have streamlined TCP and UDP that takes advantage of the new protocol. Everyone's calling upon SCTP. Implementing similar techniques on multiple transport protocols calls for a transport-session separation. -- Octavio.
Re: Google's QUIC
In the presence of layer-3 load-balancers, a multiplexed transport has the potential to allow the different data flows, coming and going to a client, to be served on a single server. - Google I'll drink the juice On Fri, Jun 28, 2013 at 2:39 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas m...@mtcc.com wrote: http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 Sounds like a UDP replacement. If this is true, then OS-level support will be needed. If they are on this, then it's the perfect opportunity to fix some other problems with the Internet in general. I'm no genius, but doesn't the article say it's UDP? (in the name of the protocol even) -chris -- Phil Fagan Denver, CO 970-480-7618
Re: Google's QUIC
The idea reminds me of uTP in terms of congestion handling. -- Tassos Josh Hoppes wrote on 28/6/2013 23:16: My first question is, how are they going to keep themselves from congesting links? On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas m...@mtcc.com wrote: http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 Sorry if this is a little more on the dev side, and less on the ops side but since it's Google, it will almost certainly affect the ops side eventually. My first reaction to this was why not SCTP, but apparently they think that middle boxen/firewalls make it problematic. That may be, but UDP based port filtering is probably not far behind on the flaky front. The second justification was TLS layering inefficiencies. That definitely has my sympathies as TLS (especially cert exchange) is bloated and the way that it was grafted onto TCP wasn't exactly the most elegant. Interestingly enough, their main justification wasn't a security concern so much as helpful middle boxen getting their filthy mitts on the traffic and screwing it up. The last thing that occurs to me reading their FAQ is that they are seemingly trying to send data with 0 round trips. That is, SYN, data, data, data... That really makes me wonder about security/dos considerations. As in, it sounds too good to be true. But maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm. Other comments or clue? Mike
Re: Google's QUIC
On Fri, Jun 28, 2013 at 4:48 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: Sounds like a UDP replacement. If this is true, then OS-level support will be needed. If they are on this, then it's the perfect opportunity to fix some other problems with the Internet in general. I'm no genius, but doesn't the article say it's UDP? (in the name of the protocol even) I was trying to emphasize replacement, not UDP. This is, that works on the same layer, that requires OS-level modifications, as opposed to a again... not a super smart on this stuff, but.. why does it require OS modifications? isn't this just going be 'chrome' (or 'other application') asking for a udp socket and spewing line-rate-foo out of that? isn't the application going to be doing all of the multiplexing and jankiness? protocol that could be similar to UDP but work on the application layer. it's not 'similar to UDP', it is in fact UDP, from what I read in the article. My point was that all that work could be focused on a *really* good transport (even with end-user multihoming without bloating the routing how's that sctp going for you? lisp? sham6? table), and have streamlined TCP and UDP that takes advantage of the new protocol. sure, ilnp? Everyone's calling upon SCTP. Implementing similar techniques on multiple transport protocols calls for a transport-session separation. right, and the 1 application using sctp is so wide spread we've all heard of it even. possibly this will be a similar diversion into protocol/application testing even. -chris
Re: Google's QUIC
On Fri, Jun 28, 2013 at 4:49 PM, Phil Fagan philfa...@gmail.com wrote: In the presence of layer-3 load-balancers, a multiplexed transport has the potential to allow the different data flows, coming and going to a client, to be served on a single server. - Google I'll drink the juice i don't think much juice is required... doesn't that just say that the same 'flow' will follow the same path through the network? and that most/all (save a10/yahoo!) loadbalancers just LB based on 5-tuple (at best)? so keeping things in a single flow/stream/5-tuple will drop packets from one host deterministicaly on a single other host at the far side?
Re: Google's QUIC
I took that as path agnostic. On Fri, Jun 28, 2013 at 3:00 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 4:49 PM, Phil Fagan philfa...@gmail.com wrote: In the presence of layer-3 load-balancers, a multiplexed transport has the potential to allow the different data flows, coming and going to a client, to be served on a single server. - Google I'll drink the juice i don't think much juice is required... doesn't that just say that the same 'flow' will follow the same path through the network? and that most/all (save a10/yahoo!) loadbalancers just LB based on 5-tuple (at best)? so keeping things in a single flow/stream/5-tuple will drop packets from one host deterministicaly on a single other host at the far side? -- Phil Fagan Denver, CO 970-480-7618
Re: Google's QUIC
- Original Message - From: Michael Thomas m...@mtcc.com My first reaction to this was why not SCTP, but apparently they think Simple Computer Telephony Protocol? Did anyone ever actually implement that? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Google's QUIC
On 06/28/2013 02:07 PM, Jay Ashworth wrote: - Original Message - From: Michael Thomas m...@mtcc.com My first reaction to this was why not SCTP, but apparently they think Simple Computer Telephony Protocol? Did anyone ever actually implement that? No: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol *Mike*
Re: Google's QUIC
--- m...@mtcc.com wrote: From: Michael Thomas m...@mtcc.com On 06/28/2013 02:07 PM, Jay Ashworth wrote: - Original Message - From: Michael Thomas m...@mtcc.com My first reaction to this was why not SCTP, but apparently they think Simple Computer Telephony Protocol? Did anyone ever actually implement that? No: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol --- C'mon Jay! Get with the plan! ;-) scott
Re: Google's QUIC
On 6/28/13 2:15 PM, Michael Thomas wrote: On 06/28/2013 02:07 PM, Jay Ashworth wrote: - Original Message - From: Michael Thomas m...@mtcc.com My first reaction to this was why not SCTP, but apparently they think Simple Computer Telephony Protocol? Did anyone ever actually implement that? No: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol SCTP is used successfully for the purpose for which it was intended, which is connecting SS7 switches over IP. It's not as much a posterchild for an application agnostic transport as some people would like to think. *Mike*
Re: Google's QUIC
On Fri, 28 Jun 2013 14:28:39 -0700, joel jaeggli said: SCTP is used successfully for the purpose for which it was intended, which is connecting SS7 switches over IP. It's not as much a posterchild for an application agnostic transport as some people would like to think. OK, I'll bite... does anything else notable actually use it? pgpb1GCjZJePG.pgp Description: PGP signature
Re: Google's QUIC
On 06/28/2013 02:28 PM, joel jaeggli wrote: On 6/28/13 2:15 PM, Michael Thomas wrote: On 06/28/2013 02:07 PM, Jay Ashworth wrote: - Original Message - From: Michael Thomas m...@mtcc.com My first reaction to this was why not SCTP, but apparently they think Simple Computer Telephony Protocol? Did anyone ever actually implement that? No: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol SCTP is used successfully for the purpose for which it was intended, which is connecting SS7 switches over IP. It's not as much a posterchild for an application agnostic transport as some people would like to think. Well, I'm pretty sure that Randy Stewart has a more expansive take on SCTP than SS7oIP, but I get the impression that there just weren't enough other things that cared about head of line blocking. But now, 15 years later, it seems like maybe there is. In any case, if what you're worried about is head of line blocking, SCTP definitely does that, and there are kernel implementations so for an *experiment* it seems like you could get a long way by ignoring its warts. But I think the most provocative thing is the idea of sending data payloads prior to handshake. That sort of scares me because of the potential for an amplification attack. But I haven't actually read the protocol paper itself. Mike
The Cidr Report
This report has been generated at Fri Jun 28 21:13:56 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
21-06-13457753 260974
22-06-13458159 261160
23-06-13458638 261324
24-06-13458895 261148
25-06-13458130 265776
26-06-13466890 265811
27-06-13467134 265159
28-06-13467649 265318
AS Summary
44524 Number of ASes in routing system
18376 Number of ASes announcing only one prefix
4237 Largest number of prefixes announced by an AS
AS7029 : WINDSTREAM - Windstream Communications Inc
116932576 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 28Jun13 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 467629 265381 20224843.2% All ASes
AS6389 2991 74 291797.5% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS28573 2902 105 279796.4% NET Serviços de Comunicação
S.A.
AS7029 4237 2108 212950.2% WINDSTREAM - Windstream
Communications Inc
AS17974 2561 525 203679.5% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS4766 2930 936 199468.1% KIXS-AS-KR Korea Telecom
AS10620 2677 848 182968.3% Telmex Colombia S.A.
AS22773 1986 170 181691.4% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS18566 2064 474 159077.0% COVAD - Covad Communications
Co.
AS4323 2979 1522 145748.9% TWTC - tw telecom holdings,
inc.
AS7303 1731 453 127873.8% Telecom Argentina S.A.
AS7545 2021 750 127162.9% TPG-INTERNET-AP TPG Telecom
Limited
AS4755 1748 585 116366.5% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS18881 1069 44 102595.9% Global Village Telecom
AS7552 1159 142 101787.7% VIETEL-AS-AP Vietel
Corporation
AS2118 1085 86 99992.1% RELCOM-AS OOO NPO Relcom
AS36998 1237 301 93675.7% SDN-MOBITEL
AS1785 1995 1152 84342.3% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS18101 1002 182 82081.8% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS33363 2021 1241 78038.6% BHN-TAMPA - BRIGHT HOUSE
NETWORKS, LLC
AS4808 1148 393 75565.8% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS701 1533 803 73047.6% UUNET - MCI Communications
Services, Inc. d/b/a Verizon
Business
AS13977 845 138 70783.7% CTELCO - FAIRPOINT
COMMUNICATIONS, INC.
AS22561 1193 517 67656.7% DIGITAL-TELEPORT - Digital
Teleport Inc.
AS855728 54 67492.6% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS6983 1145 478 66758.3% ITCDELTA - ITC^Deltacom
AS8151 1266 602 66452.4% Uninet S.A. de C.V.
AS24560 1080 417 66361.4% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS17676 735 112 62384.8% GIGAINFRA Softbank BB Corp.
AS8402 1647 1051 59636.2% CORBINA-AS OJSC Vimpelcom
AS31148 803 208
BGP Update Report
BGP Update Report Interval: 20-Jun-13 -to- 27-Jun-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS35819 44046 2.2% 93.7 -- MOBILY-AS Etihad Etisalat Company (Mobily) 2 - AS47331 34189 1.7% 16.1 -- TTNET TTNet A.S. 3 - AS840231907 1.6% 25.4 -- CORBINA-AS OJSC Vimpelcom 4 - AS982930085 1.5% 31.9 -- BSNL-NIB National Internet Backbone 5 - AS27738 26279 1.3% 45.9 -- Ecuadortelecom S.A. 6 - AS755223804 1.2% 15.9 -- VIETEL-AS-AP Vietel Corporation 7 - AS453822791 1.1% 43.7 -- ERX-CERNET-BKB China Education and Research Network Center 8 - AS17974 22234 1.1% 8.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 9 - AS958321563 1.1% 16.7 -- SIFY-AS-IN Sify Limited 10 - AS941617229 0.8% 297.1 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 11 - AS671314767 0.7% 27.2 -- IAM-AS 12 - AS37004 13691 0.7% 652.0 -- SUBURBAN-AS 13 - AS60974 13041 0.7% 255.7 -- NAICOMS Naicoms EOOD 14 - AS12252 11023 0.6% 73.5 -- America Movil Peru S.A.C. 15 - AS27947 10791 0.5% 21.3 -- Telconet S.A 16 - AS29049 10705 0.5% 31.6 -- DELTA-TELECOM-AS Delta Telecom LTD. 17 - AS269710396 0.5% 110.6 -- ERX-ERNET-AS Education and Research Network 18 - AS28573 10382 0.5% 7.5 -- NET Serviços de Comunicação S.A. 19 - AS475510146 0.5% 7.7 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 20 - AS458999838 0.5% 26.3 -- VNPT-AS-VN VNPT Corp TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS9854 6668 0.3%6668.0 -- KTO-AS-KR KTO 2 - AS6174 6108 0.3%3054.0 -- SPRINTLINK8 - Sprint 3 - AS362252953 0.1%2953.0 -- INFINITEIT-ASN-01 - Infinite IT Solutions Inc. 4 - AS8137 4762 0.2%2381.0 -- DISNEYONLINE-AS - Disney Online 5 - AS369762130 0.1%2130.0 -- SONANGOL 6 - AS373673513 0.2%1756.5 -- CALLKEY 7 - AS423343609 0.2%1203.0 -- BBP-AS Broadband Plus s.a.l. 8 - AS354131124 0.1%1124.0 -- SL-NETWORKS SL Networks SRL 9 - AS110172091 0.1%1045.5 -- CSN - CSN Support Services 10 - AS611411032 0.1%1032.0 -- OST-AS OST CJSC 11 - AS37551 0.4%1502.0 -- CMED-AS Cmed Technology Ltd 12 - AS37004 13691 0.7% 652.0 -- SUBURBAN-AS 13 - AS222165632 0.3% 625.8 -- SIEMENS-PLM - Siemens Corporation 14 - AS486128636 0.4% 616.9 -- RTC-ORENBURG-AS CJSC Comstar-Regions 15 - AS104453922 0.2% 560.3 -- HTG - Huntleigh Telcom 16 - AS55150 555 0.0% 555.0 -- DST-01 - DST Resources 17 - AS349693840 0.2% 480.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 18 - AS50797 461 0.0% 461.0 -- ELIXE-AS Elixe Co. Ltd 19 - AS57851 439 0.0% 439.0 -- GENESIS-HOUSING-ASSOCIATION-LIMITED Genesis Housing Association Limited 20 - AS22688 829 0.0% 414.5 -- DOLGENCORP - Dollar General Corporation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.118.224.0/21 8581 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 2 - 92.246.207.0/248572 0.4% AS48612 -- RTC-ORENBURG-AS CJSC Comstar-Regions 3 - 203.118.232.0/21 8543 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 4 - 202.41.70.0/24 7890 0.4% AS2697 -- ERX-ERNET-AS Education and Research Network 5 - 192.58.232.0/247776 0.4% AS6629 -- NOAA-AS - NOAA 6 - 211.214.206.0/24 6668 0.3% AS9854 -- KTO-AS-KR KTO 7 - 192.107.15.0/245126 0.2% AS14733 -- AS14733 - Barclays Capital Inc. 8 - 198.187.189.0/24 4759 0.2% AS8137 -- DISNEYONLINE-AS - Disney Online 9 - 194.63.9.0/24 4589 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 10 - 64.187.64.0/23 4037 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 11 - 173.232.234.0/24 4020 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 12 - 173.232.235.0/24 4017 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 13 - 69.38.178.0/24 4016 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 14 - 62.84.76.0/24 3601 0.2% AS42334 -- BBP-AS Broadband Plus s.a.l. 15 - 41.75.40.0/21 3510 0.2% AS37367 -- CALLKEY 16 - 64.187.64.0/24 3436 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 17 - 206.105.75.0/243054 0.1% AS6174 -- SPRINTLINK8 - Sprint 18 - 208.16.110.0/243054 0.1% AS6174 -- SPRINTLINK8 - Sprint 19 - 216.27.253.0/242998
Re: Google's QUIC
On Fri, Jun 28, 2013 at 1:23 PM, Michael Thomas m...@mtcc.com wrote: On 06/28/2013 01:16 PM, Josh Hoppes wrote: My first question is, how are they going to keep themselves from congesting links? The FAQ claims they're paying attention to that, but I haven't read the details. I sure hope they grok that not understanding Van Jacobson dooms you to repeat it. Van is at Google. Much grokking is going on. -Scott https://docs.google.com/**document/d/**1lmL9EF6qKrk7gbazY8bIdvq3Pno2X** j_l_YShP40GLQE/preview?sle=**true#heading=h.h3jsxme7rovmhttps://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/preview?sle=true#heading=h.h3jsxme7rovm Mike On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas m...@mtcc.com wrote: http://arstechnica.com/**information-technology/2013/** 06/google-making-the-web-**faster-with-protocol-that-** reduces-round-trips/?comments=**1http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 Sorry if this is a little more on the dev side, and less on the ops side but since it's Google, it will almost certainly affect the ops side eventually. My first reaction to this was why not SCTP, but apparently they think that middle boxen/firewalls make it problematic. That may be, but UDP based port filtering is probably not far behind on the flaky front. The second justification was TLS layering inefficiencies. That definitely has my sympathies as TLS (especially cert exchange) is bloated and the way that it was grafted onto TCP wasn't exactly the most elegant. Interestingly enough, their main justification wasn't a security concern so much as helpful middle boxen getting their filthy mitts on the traffic and screwing it up. The last thing that occurs to me reading their FAQ is that they are seemingly trying to send data with 0 round trips. That is, SYN, data, data, data... That really makes me wonder about security/dos considerations. As in, it sounds too good to be true. But maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm. Other comments or clue? Mike
Re: Google's QUIC
On 29.06.2013, at 1:38, valdis.kletni...@vt.edu wrote: On Fri, 28 Jun 2013 14:28:39 -0700, joel jaeggli said: SCTP is used successfully for the purpose for which it was intended, which is connecting SS7 switches over IP. It's not as much a posterchild for an application agnostic transport as some people would like to think. OK, I'll bite... does anything else notable actually use it? Well it mostly non-user stuff, Netflow exporting, diameter, sip. Wait webrtc using it, firefox and chrome have sctp code, last time a checked
Charter - IPv6 peering
Anyone from Charter have any information on when IPv6 peering will be available to Charter Business customers? My response from support was Charter is not currently providing IPV6 customer peering Looking back in the NANOG archives, I see back in May there was mention of a field trial for Charter Business customers. Did that become a thing? -Robert
Re: Charter - IPv6 peering
Looking back in the NANOG archives, I see back in May there was mention of a field trial for Charter Business customers. Did that become a thing? Forgot to add, that is May of *2012*
Re: Google's QUIC
On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: again... not a super smart on this stuff, but.. why does it require OS modifications? isn't this just going be 'chrome' (or 'other application') asking for a udp socket and spewing line-rate-foo out of that? isn't the application going to be doing all of the multiplexing and jankiness? I hope not. What would be the point of only letting one application take the benefit of all those improvements? If we're able to identify clear performance wins, our hope is to collaborate with the rest of the community to develop the features and techniques of QUIC into network standards. So yes, QUIC itself doesn't require OS-level modifications, but letting stay there is pointless. protocol that could be similar to UDP but work on the application layer. it's not 'similar to UDP', it is in fact UDP, from what I read in the article. Well, it runs on top of UDP, but it is NOT UDP. My guess is that UDP is needed just to work through NAT. My point was that all that work could be focused on a *really* good transport (even with end-user multihoming without bloating the routing how's that sctp going for you? lisp? sham6? That's the point exactly. Google has more power and popularity to influence adoption of a protocol, just like with SPDY and QUIC. Neither of the three are widely implemented. That said, neither of those enable full path resiliency. Path resiliency requires the end-point to be available through different paths and being able to detect those paths *before* the first connection is established. SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is IPv6-specific and can help you recover an already successful connection. LISP... I can't still grasp LISP, although it doesn't have anything to do with multihoming. :-) table), and have streamlined TCP and UDP that takes advantage of the new protocol. sure, ilnp? ILNP is new for me. Looks interesting, thanks. -- Octavio.
Re: Charter - IPv6 peering
On 6/28/13 3:16 PM, Robert Glover wrote: Anyone from Charter have any information on when IPv6 peering will be available to Charter Business customers? My response from support was Charter is not currently providing IPV6 customer peering Looking back in the NANOG archives, I see back in May there was mention of a field trial for Charter Business customers. Did that become a thing? I've had native IPv6 from Charter since January 2013. ~Seth
Re: Charter - IPv6 peering
On 6/28/2013 3:27 PM, Seth Mattinen wrote: I've had native IPv6 from Charter since January 2013. ~Seth Are you a Charter Business fiber customer doing BGP with IPv6 PI space? -Robert
Re: Charter - IPv6 peering
On 6/28/13 3:36 PM, Robert Glover wrote: On 6/28/2013 3:27 PM, Seth Mattinen wrote: I've had native IPv6 from Charter since January 2013. ~Seth Are you a Charter Business fiber customer doing BGP with IPv6 PI space? Yes to all. They're one of the providers I multihome with. ~Seth
Re: Google's QUIC
On Jun 28, 2013 6:24 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: again... not a super smart on this stuff, but.. protocol that could be similar to UDP but work on the application layer. it's not 'similar to UDP', it is in fact UDP, from what I read in the article. Well, it runs on top of UDP, but it is NOT UDP. My guess is that UDP is needed just to work through NAT. Runs in top of UDP... Is not UDP... If it has protocol set to 17 it is UDP. My point was that all that work could be focused on a *really* good transport (even with end-user multihoming without bloating the routing how's that sctp going for you? lisp? sham6? That's the point exactly. Google has more power and popularity to influence adoption of a protocol, just like with SPDY and QUIC. Neither of the three are widely implemented. That said, neither of those enable full path resiliency. Path resiliency requires the end-point to be available through different paths and being able to detect those paths *before* the first connection is established. SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is IPv6-specific and can help you recover an already successful connection. LISP... I can't still grasp LISP, although it doesn't have anything to do with multihoming. :-) Lisp is actually very much about multihoming... In fact that was one of the key reasons it got started. It actually could make multihoming and mobility very much simpler at the applications if it were used. It is a bit complex though... At least for normal ivp4/6 routing minded folk. table), and have streamlined TCP and UDP that takes advantage of the new protocol. sure, ilnp? ILNP is new for me. Looks interesting, thanks. Mind that ilnp is v6only also requires stack changes...
Re: Service provider T1/PPP question
On 06/28/2013 12:56 PM, Naslund, Steve wrote: I think this post seems like a flashback. I would not consider a T-1 to really be broadband anymore and it is pretty much limited to a business environment the way tariffs work. As far as MLPPP, it seems to be pretty stable now where you need multiple bonded T-1s. We have a few sites running MLPPP with Sprint on Juniper and Cisco gear and have not had an issue with it. It is definitely not my preference for business connectivity anymore. We tend to look for Ethernet service which is way cheaper per mb than T-1 and requires less expensive terminal equipment in most cases. T-1s are the business solution where you need dedicated MPLS connectivity and fiber transport is not available. DSL or Internet VPN are OK but somewhat less stable for business class private network solutions. If it is internet connectivity they want you will get beaten up by the cable companies that can outrun and outprice you across the board. You will also have a heck of a time competing with incumbent and competitive telecoms in T-1s that have central offices or collocations in central offices. The economics just don't work if you don't have direct access to the cable plant. Maybe up until the telecom act but not now. How do you intend to get those T-1s back to you or are you a CLEC? I am a clec with colocated facilities, and my targets are rural unserved areas where none of the factors above are considerations. I just want to connect with anyone who's done this and has a qualified technical opinion on optimal deployment strategies; the business considerations are already done. Thanks tho. Mike
RE: Service provider T1/PPP question
-Original Message- From: Mike [mailto:mike-na...@tiedyenetworks.com] Sent: Friday, June 28, 2013 8:26 PM To: nanog@nanog.org Subject: Re: Service provider T1/PPP question On 06/28/2013 12:56 PM, Naslund, Steve wrote: I think this post seems like a flashback. I would not consider a T-1 to really be broadband anymore and it is pretty much limited to a business environment the way tariffs work. As far as MLPPP, it seems to be pretty stable now where you need multiple bonded T-1s. We have a few sites running MLPPP with Sprint on Juniper and Cisco gear and have not had an issue with it. It is definitely not my preference for business connectivity anymore. We tend to look for Ethernet service which is way cheaper per mb than T-1 and requires less expensive terminal equipment in most cases. T-1s are the business solution where you need dedicated MPLS connectivity and fiber transport is not available. DSL or Internet VPN are OK but somewhat less stable for business class private network solutions. If it is internet connectivity they want you will get beaten up by the cable companies that can outrun and outprice you across the board. You will also have a heck of a time competing with incumbent and competitive telecoms in T-1s that have central offices or collocations in central offices. The economics just don't work if you don't have direct access to the cable plant. Maybe up until the telecom act but not now. How do you intend to get those T-1s back to you or are you a CLEC? I am a clec with colocated facilities, and my targets are rural unserved areas where none of the factors above are considerations. I just want to connect with anyone who's done this and has a qualified technical opinion on optimal deployment strategies; the business considerations are already done. Most T-1 service these days seems to be delivered over HDSL. You may also want to consider EoC. XO uses Adtran CPEs for their EoC service, anything from 1.5Mbps to 20Mbps service over 1 or more copper pairs with good distances between repeaters.
RE: Service provider T1/PPP question
The problem being a CLEC is getting access to repeater housings. Usually limits you to a few kft. At least you can get up to 15mbps/pair now. On Jun 28, 2013 6:23 PM, Eric Wieling ewiel...@nyigc.com wrote: -Original Message- From: Mike [mailto:mike-na...@tiedyenetworks.com] Sent: Friday, June 28, 2013 8:26 PM To: nanog@nanog.org Subject: Re: Service provider T1/PPP question On 06/28/2013 12:56 PM, Naslund, Steve wrote: I think this post seems like a flashback. I would not consider a T-1 to really be broadband anymore and it is pretty much limited to a business environment the way tariffs work. As far as MLPPP, it seems to be pretty stable now where you need multiple bonded T-1s. We have a few sites running MLPPP with Sprint on Juniper and Cisco gear and have not had an issue with it. It is definitely not my preference for business connectivity anymore. We tend to look for Ethernet service which is way cheaper per mb than T-1 and requires less expensive terminal equipment in most cases. T-1s are the business solution where you need dedicated MPLS connectivity and fiber transport is not available. DSL or Internet VPN are OK but somewhat less stable for business class private network solutions. If it is internet connectivity they want you will get beaten up by the cable companies that can outrun and outprice you across the board. You will also have a heck of a time competing with incumbent and competitive telecoms in T-1s that have central offices or collocations in central offices. The economics just don't work if you don't have direct access to the cable plant. Maybe up until the telecom act but not now. How do you intend to get those T-1s back to you or are you a CLEC? I am a clec with colocated facilities, and my targets are rural unserved areas where none of the factors above are considerations. I just want to connect with anyone who's done this and has a qualified technical opinion on optimal deployment strategies; the business considerations are already done. Most T-1 service these days seems to be delivered over HDSL. You may also want to consider EoC. XO uses Adtran CPEs for their EoC service, anything from 1.5Mbps to 20Mbps service over 1 or more copper pairs with good distances between repeaters.
Re: Service provider T1/PPP question
On 06/28/2013 06:21 PM, Eric Wieling wrote: I am a clec with colocated facilities, and my targets are rural unserved areas where none of the factors above are considerations. I just want to connect with anyone who's done this and has a qualified technical opinion on optimal deployment strategies; the business considerations are already done. Most T-1 service these days seems to be delivered over HDSL. You may also want to consider EoC. XO uses Adtran CPEs for their EoC service, anything from 1.5Mbps to 20Mbps service over 1 or more copper pairs with good distances between repeaters. Im already doing the above. Just need T1 for reach since EoC is only good on home runs from the CO out to some distance whereas T1 can get me into the hills beyond. Mike-
Re: Google's QUIC
On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: Runs in top of UDP... Is not UDP... If it has protocol set to 17 it is UDP. So QUIC is an algorithm instead of a protocol? SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is IPv6-specific and can help you recover an already successful connection. LISP... I can't still grasp LISP, although it doesn't have anything to do with multihoming. :-) Lisp is actually very much about multihoming... In fact that was one of the key reasons it got started. It actually could make multihoming and mobility very much simpler at the applications if it were used. Yeah, but LISP is as [in]accessible to end-users as BGP is and it will be like that forever. It requires ISPs to opt-in to provide this. LISP is not a universal option. LISP matters to the Internet core, it doesn't matter to the whole Internet. It is just not universal. ILNP is new for me. Looks interesting, thanks. Mind that ilnp is v6only also requires stack changes... I just read about ILNP. ILNP is nice if you want to multihome nodes, but virtualization (or spanning, for that matter, similar to anycasting) over multiple data-centers will reach the limitations of ILNP. It is a step ahead, but it is not an integral approach. I wish my Debian mirror would just be the mirror.debian.net *service* (not host), and the network could choose the best for me. -- Octavio.
Re: Service provider T1/PPP question
On Jun 28, 2013, at 7:26 PM, Mike mike-na...@tiedyenetworks.com wrote: I am a clec with colocated facilities, and my targets are rural unserved areas where none of the factors above are considerations. I just want to connect with anyone who's done this and has a qualified technical opinion on optimal deployment strategies; the business considerations are already done. I find this fascinating, but here's the scoop. When T1's were the bee's knees (why is that a saying, anyway?) they were sold to what today we would call a business customer. The concept of residential users as we know them know didn't really exist during T1's heyday. Also during this time period MLPPP for high speed (yes, T1's qualified wasn't really a thing, rather external multiplexers and HSSI (remember those fun cables?) into a DS3 interface were a thing. Remember providers that did Frame Relay over NxT1 just so they could mux the multiple customers on to DS-3/OC-3 into routers? Fun times...not. Anyway, the customer would have a router, like a real router, well, a 25xx anyway, and know how to configure it. That doesn't seem to be the world you're describing though, which is why I think you're getting crickets on the mailing list. Here's my $0.02, this is going to work best if you go somewhat old school in the config. HDLC or PPP over a single T1 to any equipment that supports either should more or less work just fine. Static assignment will work just fine, PPP learned assignments should work more or less just fine. Any of the things that can channelize DS-3/OC-3/OC-12/OC-48 down to T1 should work just dandy, it's all a matter of how many you have and your particular economics. Bonded T1's is where it gets interesting. MLPPP should be possible with modern hardware, but honestly it got a workout on devices that did things like ISDN, not T1's. Still, if you choose carefully I don't see any reason why MLPPP shouldn't be reliable and work just fine in today's world. If you're willing to do without modern features, you should be able to pick up a ton of gear that does all this for dirt cheap. A 7513 with channelized DS-3 cards is still quite spiffy for terminating static routed T1's for instance, and people may even pay you take them at this point. :) The CPE will be more interesting, there are several vendors that still make CPE with T1 interfaces, but that's much more rare. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Google's QUIC
On Jun 28, 2013, at 5:24 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: That's the point exactly. Google has more power and popularity to influence adoption of a protocol, just like with SPDY and QUIC. This is the main reason why I'm very supportive of this effort. I'm a bit skeptical of what I have read so far, but I know that it's nearly impossible to tell how these things really work from theory and simulations. Live, real world testing is required competing with all sorts of other flows. Google with their hands in both things like www.google.com and Chrome is in an interesting position to implement server and client side of these implementations, and turn them on and off at will. They can do the real world tests, tweak, report on them, and advance the state of the art. So for now I'll reserve judgement on this particular protocol, while encouraging Google to do more of this sort of real world testing at the protocol level. Now, how about an SCTP test? :) -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Service provider T1/PPP question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/28/2013 10:56 PM, Leo Bicknell wrote: If you're willing to do without modern features, you should be able to pick up a ton of gear that does all this for dirt cheap. A 7513 with channelized DS-3 cards is still quite spiffy for terminating static routed T1's for instance, and people may even pay you take them at this point. :) The CPE will be more interesting, there are several vendors that still make CPE with T1 interfaces, but that's much more rare. As someone else already mentioned, back in the 720x-VXR /3640 days of T1 terminations, we scaled up to 5 T1s before going to [fractional] DS3, and the old cef per-packet load balancing was wonderful provided you were talking to another Cisco endpoint (which for us, at the time, was Qwest, and yes it was). We were so sold on it that we even tried that on campus, but soon learned that Catalysts had no idea what cef per-packet meant :( So enter EIGRP / utilization load sharing... Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlHOT+gACgkQiwXJq373XhaozQCgiVGXOMIDccyONDRUQAk/M5GW 2OQAn2EfzwkvrgIl4eUsjIAGyXKq7z6s =u7Mw -END PGP SIGNATURE-
Re: Google's QUIC
On Fri, Jun 28, 2013 at 8:00 PM, Leo Bicknell bickn...@ufp.org wrote: On Jun 28, 2013, at 5:24 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: That's the point exactly. Google has more power and popularity to influence adoption of a protocol, just like with SPDY and QUIC. This is the main reason why I'm very supportive of this effort. I'm a bit skeptical of what I have read so far, but I know that it's nearly impossible to tell how these things really work from theory and simulations. Live, real world testing is required competing with all sorts of other flows. Google with their hands in both things like www.google.com and Chrome is in an interesting position to implement server and client side of these implementations, and turn them on and off at will. They can do the real world tests, tweak, report on them, and advance the state of the art. So for now I'll reserve judgement on this particular protocol, while encouraging Google to do more of this sort of real world testing at the protocol level. +1, Google is smart for doing this. It is important to push the boundaries on performance. QUIC is UDP, and UDP is the right step for now. And, hopefully this stuff gets rolled up into ILNP stack features. Yes ILNP needs stack changes, think big. Not all things can NOT be a simple incremental tweaks. ILNP will be a revolution. QUIC is simply a revolt on performance issues with TCP in today's low-loss, high latency (mobile), and middle box encumbered networks. CB Now, how about an SCTP test? :) -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: Google's QUIC
On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: Runs in top of UDP... Is not UDP... If it has protocol set to 17 it is UDP. So QUIC is an algorithm instead of a protocol? it's as much a protocol as http is.. I suppose my point is that it's some protocol which uses udp as the transport. Because of this I don't see any (really) kernel/stack changes required, right? it's just something the application needs to work out with it's peer(s). No different from http vs smtp... -chris
Re: Google's QUIC
On Jun 29, 2013 12:23 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: Runs in top of UDP... Is not UDP... If it has protocol set to 17 it is UDP. So QUIC is an algorithm instead of a protocol? it's as much a protocol as http is.. I suppose my point is that it's some protocol which uses udp as the transport. Because of this I don't see any (really) kernel/stack changes required, right? it's just something the application needs to work out with it's peer(s). No different from http vs smtp... SCTP was layer 4, if QUIC is the same, than it will too. If QUIC is layer 5 up, it won't. That might be the difference (I haven't looked into QUIC). -chris
