Re: The 100 Gbit/s problem in your network
That's not the general case, however. That's a set of specialized videos = where you know you will have a large number of consumers at each site viewing = the same video content. Kind of like the special cases you need in order for multicast to work out, hey? So it looks like the Internet noticed we had broken its multicast and found a way to work around that damage. ;-) ... 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.
Reachability problem with AS8388 [194.63.246.0/23]
Hello, Does anyone has reachability issues with AS8388? It seems i'm unable to get packets back from 194.63.246.0/23, but only if the source is my 193.136.0.0/15 block, at AS1930. It works well from my other netblocks. I'm basically performing a (non-recursive) DNS query to DNS servers within 194.63.246.0/23. I've been trying to involve upstream providers to take a deeper look at this problem, but i haven't had any luck so far. I can't even get a traceroute back to my network from anyone at AS8388. Any suggestions? Best Regards, Carlos Friaças
Re: switch 10G standalone TOR, core to DC
On Thu, Feb 7, 2013 at 12:55 PM, Nick Hilliard n...@foobar.org wrote: On 29/01/2013 11:58, Nick Hilliard wrote: None of them will do trill. The Extreme X670 and Juniper EX4550 will both do VPLS, though. The X670 won't do BGP. this is incorrect: the ex4550 will do l2vpn/l3vpn but not vpls. The X480 does vpls, but not the X670. Nick I normally just lurk but I thought I would post to clear up the confusion. Full disclosure, I am an Extreme Networks TAC engineer. The x450 does not support any VPLS/H-VPLS/MPLS and is discontinued. It was replaced with the x460 which does support VPLS/H-VPLS/VPWS. The x480 and x670 both support VPLS/H-VPLS/VPWS. The x460, x480 and x670 all support BGP. However, only the x480 can hold the BGP full-view in hardware. So while you can run BGP on the x460 or x670 they are really only suitable for iBGP. All switches require a Core license to run BGP and an MPLS license to run VPLS/H-VPLS/VPWS. Andrew
Re: switch 10G standalone TOR, core to DC
On 12/02/2013 12:09, Andrew McConachie wrote: I normally just lurk but I thought I would post to clear up the confusion. Full disclosure, I am an Extreme Networks TAC engineer. The x450 does not support any VPLS/H-VPLS/MPLS and is discontinued. It was replaced with the x460 which does support VPLS/H-VPLS/VPWS. The x480 and x670 both support VPLS/H-VPLS/VPWS. Thanks for the clarification on this. The data sheet on the x670 doesn't actually mention vpls: www.extremenetworks.com/libraries/products/DSSumX670_1777.pdf ... just that there is an mpls feature set license, but with no details of what it contains. Normally vendors can't tell enough about useful features like this, so in the absence of mentioning it I had assumed incorrectly that it wasn't supported on this platform. Maybe you could get the documentation updated to include this information, because this is an important feature? Nick
Re: The 100 Gbit/s problem in your network
On 02/11/2013 03:52 PM, Patrick W. Gilmore wrote: One of us has a different dictionary than everyone else. I'm not sure it's different dictionaries, I think you're talking past each other. Video on demand and broadcast are 2 totally different animals. For VOD, multicast is not a good fit, clearly. But for broadcast, it has a lot of potential. Most of the issues with people wanting to pause, rewind, etc. are already handled by modern DVRs, even with live programming. What I haven't seen yet in this discussion (and sorry if I've missed it) is the fact that every evening every broadcast network sends out hour after hour of what are essentially live broadcasts, in the sense that they were not available on demand before they were aired on TV that night. In addition to live broadcasts, this nightly programming is ideal for multicast, especially since nowadays most of that programming is viewed off the DVR at another time anyway. So filling up that DVR (or even watching it live) could happen over multicast just as well as it could happen over unicast. Yes, but this basically assumes that we don't/won't see a change in their video distribution model, which is actually an unknown, rather than a given. But more importantly, what's missing from this conversation is that the broadcast networks, the existing cable/satellite/etc. providers, and everyone else who has a multi-billion dollar vested interest in the way that the business is structured now would fight this tooth and nail. So we can engineer all the awesome solutions we want, they are overwhelmingly unlikely to actually happen. If Big Content can figure out a way to extract money from the end user without involving middlemen like cable and satellite providers, then we'll see a shift. There is no guarantee of an ongoing business model just because that's the way it worked. Look at what's happened to Blockbuster Video, which has gone from being a multi-billion dollar company to being well on its way to irrelevance. What you're actually likely to see is a fight tooth and nail to ignore the signs of the coming storm, but that's not going to stop the storm, is it. It will just open the door for more visionary businesses. So, boiling everything down, the two Big Questions I see are: 1) Will throwing more bandwidth at the problem effectively allow the problem to be solved more easily than getting all the technical requirements (CPE, networks, etc.) for multicast to work? I keep having this flashback to the early days of DSL and VoIP when I would hear statements like VoIP over the public Internet will never work over what are essentially that day's versions of these concerns. 2) Whether or not we'll have broadcast networks sufficiently large to make it worth the investment to solve the mcast hurdles, or if maybe their entire distribution model just undergoes a tectonic shift... which is hardly unprecedented, consider the sort of shift dialtone is experiencing w.r.t. Ma Bell's POTS plant. In the meantime, the amount of non-broadcast video available as VOD continues to grow at a staggering pace. The answer appears to be that multicast would be great if everything were to remain as-is, but that seems a poor assumption. We're still in a period where multicast would be an awesome thing to have, but we do not have it, and people are successfully moving away from the broadcast TV channel model of video distribution, to a VOD model where they can watch what they want, when they want, without being limited to the 60 hours that their DVR happens to have queued up (how quaint in this age of the mighty cloud!) If you graph that all out, the picture you get shows a declining RoI for multicast. Any businessman would look at that and advise against any significant investment in solving a problem that is already on a path to self-resolution. We know how to solve 1) by throwing bandwidth at it even if we cringe at the requisite numbers today; throwing bandwidth at it is a brute force solution that makes your C and J salespeople smile. Products like the AppleTV/iPad/etc have managed to make somewhat uncomfortable marriages out of day-after-broadcast video and VOD(*). We have clever ideas about how to solve 1) with multicast, but no real world implementations that actually work at any sort of scale, and that's such a huge impediment to implementation when compared to just scaling known bandwidth and unicast delivery technologies... We also have seen, from the advent of cable TV, that the availability of new transmission opportunities leads to decreased viewership of the OTA broadcast networks, and a growing pool of alternative video to watch. But now here's the killer. The networks that could most benefit from multicast, the existing TV networks, what's the incentive for them to develop multicast technologies, something which I expect that their distribution partners would
Re: switch 10G standalone TOR, core to DC
On Tue, Feb 12, 2013 at 1:15 PM, Nick Hilliard n...@foobar.org wrote: On 12/02/2013 12:09, Andrew McConachie wrote: I normally just lurk but I thought I would post to clear up the confusion. Full disclosure, I am an Extreme Networks TAC engineer. The x450 does not support any VPLS/H-VPLS/MPLS and is discontinued. It was replaced with the x460 which does support VPLS/H-VPLS/VPWS. The x480 and x670 both support VPLS/H-VPLS/VPWS. Thanks for the clarification on this. The data sheet on the x670 doesn't actually mention vpls: www.extremenetworks.com/libraries/products/DSSumX670_1777.pdf ... just that there is an mpls feature set license, but with no details of what it contains. Normally vendors can't tell enough about useful features like this, so in the absence of mentioning it I had assumed incorrectly that it wasn't supported on this platform. Maybe you could get the documentation updated to include this information, because this is an important feature? Nick Thanks for pointing that out. Documentation folks have been alerted. For a quick comparison of all switches I like the Comparison Guide the best. http://www.extremenetworks.com/libraries/products/MSComparisonChart_1636.pdf --Andrew
Re: The 100 Gbit/s problem in your network
Just to clarify, Patrick is right here. Assumptions: All the movies is 120 minuters long. Each movie has an average bitrate of 50 Mbit/s. (50 Mbit/s / 8 (bits) * 7 200 (2 hours) / 1000 (MB) = 45 GB). That means that the storage capacity for the movies is going to be: 10 000 000 * 45 (GB) / 1000 (TB) / 1000 (PB) = 450 PB of storage. Some of you might want to raise your hand to say that this quality of the movie is to good. Ok, so we make it 10 times smaller to 5 Mbit/s in average: 450 PB / 10 = 45 PB or 45 000 TB. If we are using 800 GB SSD drives: 45 000 TB / 0,8 TB = 56 250 SSD drives! (And we don't have any kind of backup of the content here. That need more SSD drives as well. And don't forget the power consumption). So over to the streaming part. 10 000 000 Customers watching, each with a bandwidth of 5 Mbit/s = 50 000 000 Mbit/s / 1000 (Gbit/s) = 50 000 Gbit/s. We only need 500 * 100 Gbit/s connections to solve this kind of demand. For each ISP around the world with 10 000 000 Millions of customers. Will TLMC be able to solve the 100k users watching 10 different movies? Yes. Will TLMC be able to solve the other 10 Million watching 10 Million movies. No, since your network can not handle this kind of load in the first place. One of us has a different dictionary than everyone else. Assume I have 10 million movies in my library, and 10 million active users. Further assume there are 10 movies being watched by 100K users each, and 9,999,990 movies which are being watched by 1 user each. Which has more total demand, the 10 popular movies or the long tail? This doesn't mean Netflix or Hulu or iTunes or whatever has the aforementioned demand curve. But it does mean my definition yours do not match. Either way, I challenge you to prove the long tail on one of the serious streaming services is a tiny fraction of total demand. -- //fredan The Last Mile Cache - http://tlmc.fredan.se
Re: switch 10G standalone TOR, core to DC
W dniu 2013-02-07 22:54, Sergey Marunich pisze: Hi Peter, http://www.aristanetworks.com/media/system/pdf/Datasheets/7050S_Datasheet.pdf Arista 7050S-64 48 x 10GE + 4 x 40 GE, price around 25k$ in gpl. Large buffers, supports MLAG, DCB, wire-speed L2/L3 (OSPF,BGP), but doesn't have any kind of TRILL implementation. from documentation: shared 9 MB packet buffer pool that is allocated dynamically to ports that are congested 9MB is a standard size of port buffers.. regards, Piotr
Re: The 100 Gbit/s problem in your network
You could make far more connecting your awesome prediction software to the stock market, than using it to figure out what specific content people are going to watch to cache before they decide to watch it... And if you don't have said awesome software, then how do you propose to limit the bandwidth need for the cache so you aren't burning more bandwidth than your hit rate, which is what everyone is trying to ask you (or more accurately, explain to you)? And if you're just being a plain local cache at the house/mdf, then what exactly makes it better than any other cache that doesn't get enough hit rate to be worth it to begin with at said house/mdf? -Blake On Tue, Feb 12, 2013 at 8:14 AM, fredrik danerklint fredan-na...@fredan.sewrote: Just to clarify, Patrick is right here. Assumptions: All the movies is 120 minuters long. Each movie has an average bitrate of 50 Mbit/s. (50 Mbit/s / 8 (bits) * 7 200 (2 hours) / 1000 (MB) = 45 GB). That means that the storage capacity for the movies is going to be: 10 000 000 * 45 (GB) / 1000 (TB) / 1000 (PB) = 450 PB of storage. Some of you might want to raise your hand to say that this quality of the movie is to good. Ok, so we make it 10 times smaller to 5 Mbit/s in average: 450 PB / 10 = 45 PB or 45 000 TB. If we are using 800 GB SSD drives: 45 000 TB / 0,8 TB = 56 250 SSD drives! (And we don't have any kind of backup of the content here. That need more SSD drives as well. And don't forget the power consumption). So over to the streaming part. 10 000 000 Customers watching, each with a bandwidth of 5 Mbit/s = 50 000 000 Mbit/s / 1000 (Gbit/s) = 50 000 Gbit/s. We only need 500 * 100 Gbit/s connections to solve this kind of demand. For each ISP around the world with 10 000 000 Millions of customers. Will TLMC be able to solve the 100k users watching 10 different movies? Yes. Will TLMC be able to solve the other 10 Million watching 10 Million movies. No, since your network can not handle this kind of load in the first place. One of us has a different dictionary than everyone else. Assume I have 10 million movies in my library, and 10 million active users. Further assume there are 10 movies being watched by 100K users each, and 9,999,990 movies which are being watched by 1 user each. Which has more total demand, the 10 popular movies or the long tail? This doesn't mean Netflix or Hulu or iTunes or whatever has the aforementioned demand curve. But it does mean my definition yours do not match. Either way, I challenge you to prove the long tail on one of the serious streaming services is a tiny fraction of total demand. -- //fredan The Last Mile Cache - http://tlmc.fredan.se
Re: The 100 Gbit/s problem in your network
On 12/02/13 14:14, fredrik danerklint wrote: Just to clarify, Patrick is right here. Assumptions: All the movies is 120 minuters long. Each movie has an average bitrate of 50 Mbit/s. (50 Mbit/s / 8 (bits) * 7 200 (2 hours) / 1000 (MB) = 45 GB). That means that the storage capacity for the movies is going to be: 10 000 000 * 45 (GB) / 1000 (TB) / 1000 (PB) = 450 PB of storage. Some of you might want to raise your hand to say that this quality of the movie is to good. Ok, so we make it 10 times smaller to 5 Mbit/s in average: 450 PB / 10 = 45 PB or 45 000 TB. If we are using 800 GB SSD drives: 45 000 TB / 0,8 TB = 56 250 SSD drives! (And we don't have any kind of backup of the content here. That need more SSD drives as well. And don't forget the power consumption). So over to the streaming part. 10 000 000 Customers watching, each with a bandwidth of 5 Mbit/s = 50 000 000 Mbit/s / 1000 (Gbit/s) = 50 000 Gbit/s. We only need 500 * 100 Gbit/s connections to solve this kind of demand. For each ISP around the world with 10 000 000 Millions of customers. Will TLMC be able to solve the 100k users watching 10 different movies? Yes. Will TLMC be able to solve the other 10 Million watching 10 Million movies. No, since your network can not handle this kind of load in the first place. Fortunately, we have some fascinating recent research on exactly this: http://www.land.ufrj.br/~classes/coppe-redes-2012/trabalho/youtube_imc07.pdf -- N.
Re: Reachability problem with AS8388 [194.63.246.0/23]
Can you provide the traceroute? -Grant On Tue, Feb 12, 2013 at 6:01 AM, Carlos Friacas cfria...@fccn.pt wrote: Hello, Does anyone has reachability issues with AS8388? It seems i'm unable to get packets back from 194.63.246.0/23, but only if the source is my 193.136.0.0/15 block, at AS1930. It works well from my other netblocks. I'm basically performing a (non-recursive) DNS query to DNS servers within 194.63.246.0/23. I've been trying to involve upstream providers to take a deeper look at this problem, but i haven't had any luck so far. I can't even get a traceroute back to my network from anyone at AS8388. Any suggestions? Best Regards, Carlos Friaças
Re: switch 10G standalone TOR, core to DC
On 12/02/2013 14:23, Piotr wrote: shared 9 MB packet buffer pool that is allocated dynamically to ports that are congested 9MB is a standard size of port buffers.. That's pretty standard for a cut-thru ToR switch of this style. Cut-thru switches generally need a lot less packet buffer space than store-n-forward switches. Also, ToR boxes tend not to have complex qos requirements. Having said that, you need to be careful deploying small-buffer boxes. If you're not careful, you will end up with bad packet loss. Nick
Re: Reachability problem with AS8388 [194.63.246.0/23]
On Tue, 12 Feb 2013, Grant Ridder wrote: Hello, Can you provide the traceroute? Yes. Please see below. We were already told they drop icmp packets making the traceroute useless beyond 62.38.94.98 I strongly suspect there is an issue only on the return path, but i would need a traceroute originated at the other end so i can be sure and understand where the packets (tcp udp) are exactly being dropped. Regards, Carlos Friaças # traceroute 194.63.247.20 traceroute to 194.63.247.20 (194.63.247.20), 30 hops max, 60 byte packets 1 193.136.2.29 (193.136.2.29) 0.278 ms 0.256 ms 0.241 ms 2 ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) 0.294 ms 0.282 ms 0.269 ms 3 fccn.mx2.lis.pt.geant.net (62.40.124.97) 0.332 ms 0.320 ms 0.337 ms 4 xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) 12.650 ms 12.725 ms 12.641 ms 5 as2.rt1.gen.ch.geant2.net (62.40.112.25) 34.808 ms 34.791 ms 34.863 ms 6 ae3.rt1.fra.de.geant2.net (62.40.112.161) 43.062 ms 43.022 ms 43.010 ms 7 te0-7-0-5.ccr22.fra03.atlas.cogentco.com (149.6.42.73) 43.724 ms 43.808 ms 43.889 ms 8 te0-0-0-2.ccr22.ams03.atlas.cogentco.com (130.117.3.89) 50.106 ms te0-2-0-2.ccr22.ams03.atlas.cogentco.com (130.117.1.65) 50.240 ms te0-0-0-2.ccr22.ams03.atlas.cogentco.com (130.117.3.89) 50.114 ms 9 te0-2-0-0.ccr22.lon13.atlas.cogentco.com (130.117.1.170) 55.518 ms te0-0-0-0.ccr22.lon13.atlas.cogentco.com (130.117.1.225) 55.453 ms te0-5-0-0.ccr22.lon13.atlas.cogentco.com (154.54.61.154) 55.689 ms 10 te0-1-0-0.ccr22.lon01.atlas.cogentco.com (154.54.57.178) 55.570 ms te0-4-0-0.ccr22.lon01.atlas.cogentco.com (130.117.0.205) 55.452 ms te0-2-0-0.ccr22.lon01.atlas.cogentco.com (154.54.57.174) 55.481 ms 11 te2-1.mag02.lon01.atlas.cogentco.com (154.54.74.114) 55.439 ms 55.356 ms 55.342 ms 12 149.6.187.234 (149.6.187.234) 55.370 ms 55.451 ms 55.493 ms 13 POS00-07-00-03.med00.brd.hol.gr (62.38.36.13) 127.954 ms * 127.106 ms 14 tengigaeth00-01-00-02.med00.ccr.hol.gr (62.38.97.29) 136.321 ms * * 15 tengigaeth00-07-00-00.med00.csr.hol.gr (62.38.94.98) 125.525 ms 125.519 ms 125.584 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * -Grant On Tue, Feb 12, 2013 at 6:01 AM, Carlos Friacas cfria...@fccn.pt wrote: Hello, Does anyone has reachability issues with AS8388? It seems i'm unable to get packets back from 194.63.246.0/23, but only if the source is my 193.136.0.0/15 block, at AS1930. It works well from my other netblocks. I'm basically performing a (non-recursive) DNS query to DNS servers within 194.63.246.0/23. I've been trying to involve upstream providers to take a deeper look at this problem, but i haven't had any luck so far. I can't even get a traceroute back to my network from anyone at AS8388. Any suggestions? Best Regards, Carlos Friaças
Re: Reachability problem with AS8388 [194.63.246.0/23]
Traceroute to the same address from a TWTC circuit in Milwaukee, Wi drops in the same network as you. 7 7 ms 6 ms 7 ms xe-7-3-0.edge4.Chicago3.Level3.net[4.53.98.45] 8 114 ms 110 ms 113 ms vlan52.ebr2.Chicago2.Level3.net[4.69.138.190] 9 112 ms 110 ms 111 ms ae-6-6.ebr2.Washington12.Level3.net[4.69.148.145] 10 113 ms 113 ms 114 ms ae-5-5.ebr2.Washington1.Level3.net[4.69.143.221] 11 113 ms 109 ms 109 ms ae-43-43.ebr2.Paris1.Level3.net[4.69.137.57] 12 111 ms 111 ms 115 ms ae-45-45.ebr1.Frankfurt1.Level3.net[4.69.143.133] 13 111 ms 111 ms 111 ms ae-81-81.csw3.Frankfurt1.Level3.net[4.69.140.10] 14 110 ms 107 ms 109 ms ae-3-80.edge1.Frankfurt1.Level3.net[4.69.154.133] 15 190 ms 189 ms 183 ms 212.162.9.6 16 *** Request timed out. 17 176 ms 169 ms 169 ms tengigaeth00-00-00-00.adr00.csr.hol.gr[62.38.93.98] 18 *** Request timed out. 19 *** Request timed out. 20 *** Request timed out. 21 *** Request timed out. 22 ^C On Tue, Feb 12, 2013 at 9:52 AM, Carlos Friacas cfria...@fccn.pt wrote: On Tue, 12 Feb 2013, Grant Ridder wrote: Hello, Can you provide the traceroute? Yes. Please see below. We were already told they drop icmp packets making the traceroute useless beyond 62.38.94.98 I strongly suspect there is an issue only on the return path, but i would need a traceroute originated at the other end so i can be sure and understand where the packets (tcp udp) are exactly being dropped. Regards, Carlos Friaças # traceroute 194.63.247.20 traceroute to 194.63.247.20 (194.63.247.20), 30 hops max, 60 byte packets 1 193.136.2.29 (193.136.2.29) 0.278 ms 0.256 ms 0.241 ms 2 ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) 0.294 ms 0.282 ms 0.269 ms 3 fccn.mx2.lis.pt.geant.net (62.40.124.97) 0.332 ms 0.320 ms 0.337 ms 4 xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) 12.650 ms 12.725 ms 12.641 ms 5 as2.rt1.gen.ch.geant2.net (62.40.112.25) 34.808 ms 34.791 ms 34.863 ms 6 ae3.rt1.fra.de.geant2.net (62.40.112.161) 43.062 ms 43.022 ms 43.010 ms 7 te0-7-0-5.ccr22.fra03.atlas.**cogentco.comhttp://te0-7-0-5.ccr22.fra03.atlas.cogentco.com(149.6.42.73) 43.724 ms 43.808 ms 43.889 ms 8 te0-0-0-2.ccr22.ams03.atlas.**cogentco.comhttp://te0-0-0-2.ccr22.ams03.atlas.cogentco.com(130.117.3.89) 50.106 ms te0-2-0-2.ccr22.ams03.atlas.**cogentco.comhttp://te0-2-0-2.ccr22.ams03.atlas.cogentco.com(130.117.1.65) 50.240 ms te0-0-0-2.ccr22.ams03.atlas.**cogentco.comhttp://te0-0-0-2.ccr22.ams03.atlas.cogentco.com(130.117.3.89) 50.114 ms 9 te0-2-0-0.ccr22.lon13.atlas.**cogentco.comhttp://te0-2-0-0.ccr22.lon13.atlas.cogentco.com(130.117.1.170) 55.518 ms te0-0-0-0.ccr22.lon13.atlas.**cogentco.comhttp://te0-0-0-0.ccr22.lon13.atlas.cogentco.com(130.117.1.225) 55.453 ms te0-5-0-0.ccr22.lon13.atlas.**cogentco.comhttp://te0-5-0-0.ccr22.lon13.atlas.cogentco.com(154.54.61.154) 55.689 ms 10 te0-1-0-0.ccr22.lon01.atlas.**cogentco.comhttp://te0-1-0-0.ccr22.lon01.atlas.cogentco.com(154.54.57.178) 55.570 ms te0-4-0-0.ccr22.lon01.atlas.**cogentco.comhttp://te0-4-0-0.ccr22.lon01.atlas.cogentco.com(130.117.0.205) 55.452 ms te0-2-0-0.ccr22.lon01.atlas.**cogentco.comhttp://te0-2-0-0.ccr22.lon01.atlas.cogentco.com(154.54.57.174) 55.481 ms 11 te2-1.mag02.lon01.atlas.**cogentco.comhttp://te2-1.mag02.lon01.atlas.cogentco.com(154.54.74.114) 55.439 ms 55.356 ms 55.342 ms 12 149.6.187.234 (149.6.187.234) 55.370 ms 55.451 ms 55.493 ms 13 POS00-07-00-03.med00.brd.hol.**grhttp://POS00-07-00-03.med00.brd.hol.gr(62.38.36.13) 127.954 ms * 127.106 ms 14 tengigaeth00-01-00-02.med00.**ccr.hol.grhttp://tengigaeth00-01-00-02.med00.ccr.hol.gr(62.38.97.29) 136.321 ms * * 15 tengigaeth00-07-00-00.med00.**csr.hol.grhttp://tengigaeth00-07-00-00.med00.csr.hol.gr(62.38.94.98) 125.525 ms 125.519 ms 125.584 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * -Grant On Tue, Feb 12, 2013 at 6:01 AM, Carlos Friacas cfria...@fccn.pt wrote: Hello, Does anyone has reachability issues with AS8388? It seems i'm unable to get packets back from 194.63.246.0/23, but only if the source is my 193.136.0.0/15 block, at AS1930. It works well from my other netblocks. I'm basically performing a (non-recursive) DNS query to DNS servers within 194.63.246.0/23. I've been trying to involve upstream providers to take a deeper look at this problem, but i haven't had any luck so far. I can't even get a traceroute back to my network from anyone at AS8388. Any suggestions? Best Regards, Carlos Friaças
Re: The 100 Gbit/s problem in your network
And if you don't have said awesome software, then how do you propose to limit the bandwidth need for the cache so you aren't burning more bandwidth than your hit rate, which is what everyone is trying to ask you (or more accurately, explain to you)? Without the concept of TLMC, I don't know. I do think that I need to explain how TLMC works. (please see the file 'tlmc-20130207-r1.tar.gz' as well). This is going to be a long answer. We are trying to get the url: http://static.tlmc.csp.example/hello_world.html First the DNS needs to get the IP address of 'static.tlmc.csp.example', so we have something to connect to. What we would like to have is the IP address of a cache server at the ISP. The CSP has a 'database' of which ISP:s around the world do participate in TLMC. This information is stored in a remark field in the IRR. We do know of where the origin the DNS request is coming from, so we answer that request with a CNAME of: 'static.tlmc.csp.example' IN CNAME 'static.tlmc.csp.example.tlmc.isp.example' (If an ISP does not participate in TLMC, the CSP would instead answer with a A/ record). We now have to ask the DNS server at the ISP for an IP address to connect to. The ISP is in a good mood today, so we are getting the anycast address to connect to. (If the ISP is not in a good mode, called Offline mode in TLMC, the DNS server at the ISP will answer with a CNAME of: 'static.tlmc.csp.example.tlmc.isp.example' IN CNAME 'kaa.k.se.static.tlmc.csp.example' This assume that the DNS server was place in Karlskrona, Sweden. With this the geographic location of where a request is coming is already built in). If we have an end-user/residence which have an cache server, this is the address (the anycast one) its going to listen too. If an end-user does not have an cache server, the ISP must have one. Probably as close to the edge as possible. (Here starts the answer to your question in the beginning): These two have on thing in comment, though. They have a plug-in in the Traffic Server called, 'hash_remap' (which I made specifically for trying to solve the scenario you replied with. And Netflix's). What the plug-in will do is to change the hostname from 'static.tlmc.csp.example' to a hash-based one. In the example url giving, this will be: 'b1902023cbb5ff2597718437.tlmc.isp.example'. The first hash, 'b1902023cbb5ff25', is the combined hash of host and url. The second hash, '97718437' is the hash of the host only. With this, the ISP is going to have another DNS request. A hashed based one. Depending of how much information they are collecting from their cache servers, they know from which one they should load the content from in this case. This principle is called consistent hashing and scales very well. How many layers of consistent hashing should a ISP be using? Only they know the answer for this one. -- //fredan The Last Mile Cache - http://tlmc.fredan.se
Re: The 100 Gbit/s problem in your network
On Feb 12, 2013, at 01:06 , Doug Barton do...@dougbarton.us wrote: On 02/11/2013 03:52 PM, Patrick W. Gilmore wrote: One of us has a different dictionary than everyone else. I'm not sure it's different dictionaries, I think you're talking past each other. No, it's definitely different dictionaries. I am purposely staying out of the whole multicast vs. CDN vs. set-top caching vs. $RANDOM_TECHNOLOGY thing. I was concentrating sole on one point - that the long tail is _by definition_ a tiny fraction of total demand (Stephen's emphasis). The long tail might be a fraction, or it might be a majority of the traffic. Depends on the use case. Important to remember this discussing the pros cons of each protocol / approach. As for the rest, time will tell. But it's fun to watch the discussion, especially by people who have never attempted any of what they are espousing. :) Hey, sometimes that's where the best ideas come up - people who don't know what is impossible are not constrained! -- TTFN, patrick Video on demand and broadcast are 2 totally different animals. For VOD, multicast is not a good fit, clearly. But for broadcast, it has a lot of potential. Most of the issues with people wanting to pause, rewind, etc. are already handled by modern DVRs, even with live programming. What I haven't seen yet in this discussion (and sorry if I've missed it) is the fact that every evening every broadcast network sends out hour after hour of what are essentially live broadcasts, in the sense that they were not available on demand before they were aired on TV that night. In addition to live broadcasts, this nightly programming is ideal for multicast, especially since nowadays most of that programming is viewed off the DVR at another time anyway. So filling up that DVR (or even watching it live) could happen over multicast just as well as it could happen over unicast. But more importantly, what's missing from this conversation is that the broadcast networks, the existing cable/satellite/etc. providers, and everyone else who has a multi-billion dollar vested interest in the way that the business is structured now would fight this tooth and nail. So we can engineer all the awesome solutions we want, they are overwhelmingly unlikely to actually happen. Doug
Re: IPv6 support by wifi systems
MLD Snooping and IPv6 ACLs are a must. Check to make sure that the solution allows for many (for your network's definition of many) IPv6 addresses per host. You'll have at least three per host between link local, global, and one or more privacy addresses. I've been providing native dual stack on my Cisco controller based wireless network for a few years now. IPv6 support was brought up a notch with the 7.2 code release. RA Guard was the obvious big features that was added, but I also appreciated the addition of ND caching to keep that chatter down. http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bae506.shtml#discovery I've also used some Ruckus gear on an IPv6 network and it seemed to have all the right knobs and pass all the right IPv6 packets. Though this was on my home network so I can't speek to their IPv6 scalability (no reason to doubt it, just wanted to be clear). Feel free to ping me on or off list about either if you have more specific questions. -Luke On Mon, Feb 11, 2013 at 9:23 PM, Brandon Ross br...@pobox.com wrote: Like so many things IPv6, many of the wifi vendors seem to lack decent support for IPv6 clients. I'm not sure why I thought the situation was better than it seems to be, I guess I'm just an optimist. Anyway, what wifi vendors provide the best support for IPv6? I don't really care too much about management, but to deploy wifi in a service provider environment with IPv6, it would seem that you'd want at least: RA Guard DHCPv6 Shield (unless you just do SLAAC, I guess) IPv6 Source Address Guard Am I missing anything critical? -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross -- =-=-=-=-=-=-=-=-=-=-=-= Luke Jenkins Network Engineer Weber State University
Re: The 100 Gbit/s problem in your network
On Mon, Feb 11, 2013 at 10:05 PM, Tim Durack tdur...@gmail.com wrote: Multicast is dead. Feel free to disagree. :-) Tim: I really wish I could agree! It would have saved me some time dealing with it. There is the argument of alternative bit rates, compression, etc., but HD streams are assumed[1] at 15 Mbps. At 100Gbps, I can do max 6826 streams of HD streaming. Multicast deployments laugh at this pathetically low number of viewers. At an upstream aggregation point, I can easily serve ~128K subs (7 slots, 8 ports per slot, 3 ports per $ACCESS, 8K[3] users per $ACCESS, 1 slot for upstream). I now assume 2.5 STBs per sub[2]. This results in, more or less, 320,000 STBs. To me, the math says its not dead and we'll need a couple of orders of magnitude (to accommodate the core) in speed improvements to get the same delivery unicast. [1] http://www.cablelabs.com/specifications/OC-SP-CEP3.0-I04-121210.pdf Lists 15Mbps as safe harbor value for HD [2] http://www.aceee.org/files/proceedings/2012/data/papers/0193-000294.pdf Has some stat (good or bad) wrt STBs/household [3] uBR10K (my $ACCESS comparison) specs out for max 64K CPE. One of my guys indicates to me that the actual number might be closer to 15-25K CPE on a given node. Please make adjustments as necessary. (required note: employer is Cisco. Views are my own.) -- William McCall
Re: Muni fiber: L1 or L2?
If the L1 provider's responsibility ends at the jack on the outside NIU, as an ILEC's does today with copper, then you have clean separation and easy access for both initial installation and for later troubleshooting--clear benefits that help mitigate nearly all the problems Scott refers to, at least from the L1 provider's perspective. Stephen, I'd say this is much less clean in my experience than you're describing. In fact, I'd say that operationally its downright problematic in many territories and not improving. So if this is the model if how it should be done I think we have a long way to go before doing it in a FTTx world is remotely economical. Now, this isn't a problem in all territories or operators but it is common as dirt. -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: IPv6 support by wifi systems
On Tue, 12 Feb 2013, Luke Jenkins wrote: MLD Snooping and IPv6 ACLs are a must. MLD Snooping only seems important to me if you are actually going to do multicast outside of the local broadcast domain, which I can't imagine doing in most service provider environments. Am I missing a reason for it or a use case otherwise? Check to make sure that the solution allows for many (for your network's definition of many) IPv6 addresses per host. You'll have at least three per host between link local, global, and one or more privacy addresses. It would seem to me that either a wifi vendor would support source address shield for IPv6, which MUST include multiple addresses, or it would just pass everything without paying attention to source addresses. Is there a vendor that does not do one or the other? If so, please name names. I've been providing native dual stack on my Cisco controller based wireless network for a few years now. IPv6 support was brought up a notch with the 7.2 code release. RA Guard was the obvious big features that was added, but I also appreciated the addition of ND caching to keep that chatter down. http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bae506.shtml#discovery Nice. Can you confirm if they've added DHCPv6 shield too? Source address shield for IPv6? I've also used some Ruckus gear on an IPv6 network and it seemed to have all the right knobs and pass all the right IPv6 packets. Though this was on my home network so I can't speek to their IPv6 scalability (no reason to doubt it, just wanted to be clear). Thanks, that's a useful data point. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross
Re: The 100 Gbit/s problem in your network
I really wish I could agree! It would have saved me some time dealing with it. There is the argument of alternative bit rates, compression, etc., but HD streams are assumed[1] at 15 Mbps. At 100Gbps, I can do max 6826 streams of HD streaming. Multicast deployments laugh at this pathetically low number of viewers. At an upstream aggregation point, I can easily serve ~128K subs (7 slots, 8 ports per slot, 3 ports per $ACCESS, 8K[3] users per $ACCESS, 1 slot for upstream). I now assume 2.5 STBs per sub[2]. This results in, more or less, 320,000 STBs. Multicast for inside of a given service provider is certainly not dead and in fact its widely deployed for IPTV in DSL/FTTx networks. FIOS doesn't use it since they're not doing IPTV (traditional RFoG) but Uverse does as do most telco TV providers I've spoken with. To me, the math says its not dead and we'll need a couple of orders of magnitude (to accommodate the core) in speed improvements to get the same delivery unicast. [1] http://www.cablelabs.com/specifications/OC-SP-CEP3.0-I04-121210.pdfLists 15Mbps as safe harbor value for HD [2] http://www.aceee.org/files/proceedings/2012/data/papers/0193-000294.pdfHas some stat (good or bad) wrt STBs/household [3] uBR10K (my $ACCESS comparison) specs out for max 64K CPE. One of my guys indicates to me that the actual number might be closer to 15-25K CPE on a given node. Please make adjustments as necessary. (required note: employer is Cisco. Views are my own.) -- William McCall -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: Muni fiber: L1 or L2?
In part because I'm realizing that it is literally viable to plonk a 6509 into the colo, get a 10G uplink and pump out a bunch of 1000base?X connections (or even 100base?X) to customers at a fairly low price per port. In this case, there wouldn't be any active L2 termination at the customer other than a media converter or router with an appropriate SFP. Owen Just so you know, this isn't viable, at least not to scale. You can on the other hand use Cisco's ME line to do this even less expensively (so long as you weren't planning on buying used 6509). -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: Muni fiber: L1 or L2?
Masataka, Numbers? Examples? This is simply incorrect in many places. The only reasons to run PON are financial, since Ethernet out performs it, are you saying that all greenfield PON installs are cheaper done as Ethernet without exception? On Mon, Feb 11, 2013 at 7:42 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Stephen Sprunk wrote: The fiber plant would presumably be paid for with 30-year bonds, same as any other municipal infrastructure (eg. water and sewer lines--the real pipes), for which interest rates are currently running around the rate of inflation. There is no need to pay them off quickly. In addition, as PON is even less efficient initially when subscriber density is low and there are few subscribers to share a field splitter (unless extremely lengthy drop cables are used, which costs a lot), PON is slower to pay them off. Masataka Ohta -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: Muni fiber: L1 or L2?
I was in an Incognito user group meeting with one of the guys involved with that project two years ago and we talked about it. Its very cool and frankly extreme engineering :) He had some pictures of them dragging under sea cables themselves that blew my mind. On Mon, Feb 11, 2013 at 7:47 PM, Warren Bailey wbai...@satelliteintelligencegroup.com wrote: Though I should note that GCI was my former employer and a well respected MSO and fiber infrastructure owner/operator. They are the smartest major player I've come across, and an all around good bunch of people. From my Android phone on T-Mobile. The first nationwide 4G network. Original message From: Warren Bailey wbai...@satelliteintelligencegroup.com Date: 02/11/2013 4:44 PM (GMT-08:00) To: Stephen Sprunk step...@sprunk.org,nanog@nanog.org Subject: Re: Muni fiber: L1 or L2? Check out GCI's Terranet project. From my Android phone on T-Mobile. The first nationwide 4G network. Original message From: Stephen Sprunk step...@sprunk.org Date: 02/11/2013 4:37 PM (GMT-08:00) To: nanog@nanog.org Subject: Re: Muni fiber: L1 or L2? On 11-Feb-13 18:23, Warren Bailey wrote: On 2/11/13 4:16 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Scott Helms wrote: IMO if you can't pay for the initial build quickly and run it efficiently then your chances of long term success are very low. That is not a business model for infrastructure such as gas, electricity, CATV, water and fiber network, all of which need long term planning and investments. Nearly all of the industries you mentioned below receive some type of local or federal/government funding. If I was going to build some kind of access network, I would be banging on the .gov door asking for grants and low interest loans to help roll out broadband to remote areas. I followed the link in a recent email here to the details on the Maine Fiber Co, and their web site indicates they got started with $7M in private funding--and a $25M grant from the feds for improving service to rural areas. That radically changes the economics, just as I'm sure it did for other utilities. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: IPv6 support by wifi systems
On Tue, 2013-02-12 at 13:49 -0500, Brandon Ross wrote: MLD Snooping and IPv6 ACLs are a must. MLD Snooping only seems important to me if you are actually going to do multicast outside of the local broadcast domain MLD snooping allows the switch to send multicast traffic only to those listeners wanting to receive it. Witout MLD snooping, the switch floods multicast to all ports. May be a security issue, is definitely a traffic issue, though in a small network, it may make no difference. For example, multicast is used by ND, the IPv6 equivalent of ARP. MLD snooping means only a few hosts (typically only one, in fact) in the subnet see any given ND request. Without MLD snooping, every port in the subnet sees it. Or DHCPv6 - without MLD snooping, every port sees all client traffic for all DHCP requests; with MLD snooping only the routers/relays in the subnet see it. See with MLD snooping means see it at all, not see and ignore it as in the broadcast world. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Re: IPv6 support by wifi systems
On Wed, 13 Feb 2013, Karl Auer wrote: For example, multicast is used by ND, the IPv6 equivalent of ARP. MLD snooping means only a few hosts (typically only one, in fact) in the subnet see any given ND request. Without MLD snooping, every port in the subnet sees it. Or DHCPv6 - without MLD snooping, every port sees all client traffic for all DHCP requests; with MLD snooping only the routers/relays in the subnet see it. See with MLD snooping means see it at all, not see and ignore it as in the broadcast world. Oh really? Exactly when during the ND process does a device send an MLD message that can be snooped? -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross
Re: Muni fiber: L1 or L2?
Scott Helms wrote: Numbers? Examples? Greenfield SS and PON deployment costs in Japan was already shown. This is simply incorrect in many places. The only reasons to run PON are financial, since Ethernet out performs it, No, the only reason to insist on PON is to make L1 unbundling not feasible. are you saying that all greenfield PON installs are cheaper done as Ethernet without exception? No, SS is cheaper than PON without exception. If the initial density of subscribers is high, SS is fine. If it is not, initially, most electric equipment, OE port, fibers, splitters and a large closures containing the splitters of PON can not be shared by two or more subscribers, which means PON incurs much more material and labor cost for each initial subscriber than SS. Masataka Ohta
Re: Muni fiber: L1 or L2?
On Tue, Feb 12, 2013 at 3:47 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Scott Helms wrote: Numbers? Examples? Greenfield SS and PON deployment costs in Japan was already shown. Japan has one of the highest population densities of major economies in the world with an average density of 873 per square mile. The US on the other hand has 89 per square mile. Canada has an average density of 10 people per square mile. I would also say that Japan's consumer behavior and regulatory climate are all significantly different from the North American market so making blanket statements is pretty silly. If you want to make your case then why don't you, the only Japanese English speaker on this list I know of, extract the math behind the NTT papers and present why its cheaper in Japan and we can then see if that applies equally in the US Canada. This is simply incorrect in many places. The only reasons to run PON are financial, since Ethernet out performs it, No, the only reason to insist on PON is to make L1 unbundling not feasible. I don't know what conspiracy theory you're ascribing to here, but this is incorrect. are you saying that all greenfield PON installs are cheaper done as Ethernet without exception? No, SS is cheaper than PON without exception. Prove it. If the initial density of subscribers is high, SS is fine. If it is not, initially, most electric equipment, OE port, fibers, splitters and a large closures containing the splitters of PON can not be shared by two or more subscribers, which means PON incurs much more material and labor cost for each initial subscriber than SS. Masataka Ohta -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: IPv6 support by wifi systems
On Tue, 2013-02-12 at 15:40 -0500, Brandon Ross wrote: On Wed, 13 Feb 2013, Karl Auer wrote: For example, multicast is used by ND, the IPv6 equivalent of ARP. MLD Oh really? Exactly when during the ND process does a device send an MLD message that can be snooped? ND just uses multicast, so MLD messages are not really part of ND itself. But during the setup of any interface with an IPv6 address, MLD traffic will move and can be snooped on. The switch then knows what listeners are where, so when for example an NS is sent to the solicited node multicast address of a target during ND, the switch can send it only to those hosts it knows are listeners on that group. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Re: Muni fiber: L1 or L2?
Scott, I've been down this road with Masataka. over the last few days. I gave up. On Tue, Feb 12, 2013 at 2:59 PM, Scott Helms khe...@zcorum.com wrote: On Tue, Feb 12, 2013 at 3:47 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Scott Helms wrote: Numbers? Examples? Greenfield SS and PON deployment costs in Japan was already shown. Japan has one of the highest population densities of major economies in the world with an average density of 873 per square mile. The US on the other hand has 89 per square mile. Canada has an average density of 10 people per square mile. I would also say that Japan's consumer behavior and regulatory climate are all significantly different from the North American market so making blanket statements is pretty silly. If you want to make your case then why don't you, the only Japanese English speaker on this list I know of, extract the math behind the NTT papers and present why its cheaper in Japan and we can then see if that applies equally in the US Canada. This is simply incorrect in many places. The only reasons to run PON are financial, since Ethernet out performs it, No, the only reason to insist on PON is to make L1 unbundling not feasible. I don't know what conspiracy theory you're ascribing to here, but this is incorrect. are you saying that all greenfield PON installs are cheaper done as Ethernet without exception? No, SS is cheaper than PON without exception. Prove it. If the initial density of subscribers is high, SS is fine. If it is not, initially, most electric equipment, OE port, fibers, splitters and a large closures containing the splitters of PON can not be shared by two or more subscribers, which means PON incurs much more material and labor cost for each initial subscriber than SS. Masataka Ohta -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: IPv6 support by wifi systems
On Wed, 13 Feb 2013, Karl Auer wrote: The switch then knows what listeners are where, so when for example an NS is sent to the solicited node multicast address of a target during ND, the switch can send it only to those hosts it knows are listeners on that group. Okay, so then to answer my own question from earlier, the answer is actually that an MLD is sent when an interface configures a new address to join the appropriate solicited node multicast group. It seems that, then, MLD snooping is valuable as it will prevent DAD and other ND traffic from using bandwidth towards hosts not in that group. Other than solicited node multicast, is MLD used anywhere else in a network that does not have layer 3 multicast enabled on a router? -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross
home network monitoring and shaping
O oracle of nanog: unlike things like rogue processes eating tons of CPU, it seems to me that network monitoring is essentially a black art for the average schmuck home network operator (of which I count myself). That is: if the network is slow, it's really hard to tell why that might be and who of the eleventy seven devices on my wifi is sucking the life out of my bandwidth. And then even if I get an idea of who the perp is, my remediation choice seems to be find that device, smash it with sledge hammer. It seems that there really ought to be a better way here to manage my home network. Like, for example, the ability to get stats from router and tell it to shape various devices/flows to play nice. Right now, it seems to me that the state of the art is pretty bad -- static-y kinds of setups for static-y kinds of flows that people-y kind of users don't understand or touch on their home routers. The ob-nanog is that my intertoobs r slow is most likely a call to your support desks which is expensive, of course. Is anything happening on this front? Is openwrt, for example, paying much attention to this problem? Mike
RE: home network monitoring and shaping
Someone created an application for uverse users that goes into the gateway and pulls relevant information. The information (link retrain, for example) is then color coded for caution and out of range. The application is called up real time, not something peddled by att to show how great your connection is. People unfortunately believe a speed test is a reliable way to measure a connection quality. There may be utilities out there like this that look at signal levels and statistics to tell the user their connection blows. I believe the uvrealtime application actually shows the provider sending resets as a deterrent for using bit torrent. From my Android phone on T-Mobile. The first nationwide 4G network. Original message From: Michael Thomas m...@mtcc.com Date: 02/12/2013 1:57 PM (GMT-08:00) To: NANOG list nanog@nanog.org Subject: home network monitoring and shaping O oracle of nanog: unlike things like rogue processes eating tons of CPU, it seems to me that network monitoring is essentially a black art for the average schmuck home network operator (of which I count myself). That is: if the network is slow, it's really hard to tell why that might be and who of the eleventy seven devices on my wifi is sucking the life out of my bandwidth. And then even if I get an idea of who the perp is, my remediation choice seems to be find that device, smash it with sledge hammer. It seems that there really ought to be a better way here to manage my home network. Like, for example, the ability to get stats from router and tell it to shape various devices/flows to play nice. Right now, it seems to me that the state of the art is pretty bad -- static-y kinds of setups for static-y kinds of flows that people-y kind of users don't understand or touch on their home routers. The ob-nanog is that my intertoobs r slow is most likely a call to your support desks which is expensive, of course. Is anything happening on this front? Is openwrt, for example, paying much attention to this problem? Mike
Re: Muni fiber: L1 or L2?
Scott Helms wrote: Numbers? Examples? Greenfield SS and PON deployment costs in Japan was already shown. Japan has one of the highest population densities of major economies in the The examples are in rural area and I already stated population density in English. No, the only reason to insist on PON is to make L1 unbundling not feasible. I don't know what conspiracy theory you're ascribing to here, but this is incorrect. PON being more expensive than SS, that is the only explanation. No, SS is cheaper than PON without exception. Prove it. See above or below. If the initial density of subscribers is high, SS is fine. If it is not, initially, most electric equipment, OE port, fibers, splitters and a large closures containing the splitters of PON can not be shared by two or more subscribers, which means PON incurs much more material and labor cost for each initial subscriber than SS. Masataka Ohta
Re: Muni fiber: L1 or L2?
Jason Baugher wrote: Scott, I've been down this road with Masataka. over the last few days. I gave up. You have lost instantly, because you insisted on 32:1, which makes expensive PON even more expensive. It's stupid to insist on 32:1 to have 6 trunk fibers and 31 drop fibers within a cable for 192 subscribers, because with 8:1, you only need 24 trunk fibers and 7 drop fibers. Your theory is not consistent with the reality. Masataka Ohta
Re: Muni fiber: L1 or L2?
At this point I think the topic has been exhausted. If you participate in a conversation, try to chime in with thoughtful and insightful points. We're on here to help each other, if you want to measure girth there is probably a better venue to do so. I don't think anyone lost anything, other than a vast amount of wasted time trying to decipher your claims and opinion. It's easy to tell people how full of it they are, but if you're looking for a venue to argue (we have all done it) you should move on to greener pastures. If all of this is difficult to understand, I will summarize: Acting like a prick on a discussion list makes all of your opinions and concerns completely ignored. No one wants to deal with an arrogant prick, especially one who says someone lost because your opinion seems to be more valid to yourself. On 2/12/13 3:03 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Jason Baugher wrote: Scott, I've been down this road with Masataka. over the last few days. I gave up. You have lost instantly, because you insisted on 32:1, which makes expensive PON even more expensive. It's stupid to insist on 32:1 to have 6 trunk fibers and 31 drop fibers within a cable for 192 subscribers, because with 8:1, you only need 24 trunk fibers and 7 drop fibers. Your theory is not consistent with the reality. Masataka Ohta
Re: home network monitoring and shaping
On 02/12/2013 02:07 PM, Warren Bailey wrote: Someone created an application for uverse users that goes into the gateway and pulls relevant information. The information (link retrain, for example) is then color coded for caution and out of range. The application is called up real time, not something peddled by att to show how great your connection is. People unfortunately believe a speed test is a reliable way to measure a connection quality. There may be utilities out there like this that look at signal levels and statistics to tell the user their connection blows. I believe the uvrealtime application actually shows the provider sending resets as a deterrent for using bit torrent. It would be nice for such a thing to tell me that my ISP connection is having trouble too, but I'm mostly interested in understanding the things that are nominally under my control on my home network. It seems that most routers have (gratuitous?) apps these day, but given the awfulness of their web UI's and their configurability, I don't have much hope that they do what I want. Mike
Re: home network monitoring and shaping
I'm quite happy with what routeros (mikrotik) provides me on my home network. - Eric Eric Adler Broadcast Engineer On 2/12/13, Michael Thomas m...@mtcc.com wrote: O oracle of nanog: unlike things like rogue processes eating tons of CPU, it seems to me that network monitoring is essentially a black art for the average schmuck home network operator (of which I count myself). That is: if the network is slow, it's really hard to tell why that might be and who of the eleventy seven devices on my wifi is sucking the life out of my bandwidth. And then even if I get an idea of who the perp is, my remediation choice seems to be find that device, smash it with sledge hammer. It seems that there really ought to be a better way here to manage my home network. Like, for example, the ability to get stats from router and tell it to shape various devices/flows to play nice. Right now, it seems to me that the state of the art is pretty bad -- static-y kinds of setups for static-y kinds of flows that people-y kind of users don't understand or touch on their home routers. The ob-nanog is that my intertoobs r slow is most likely a call to your support desks which is expensive, of course. Is anything happening on this front? Is openwrt, for example, paying much attention to this problem? Mike -- Sent from my mobile device
Re: home network monitoring and shaping
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2013 21:56, Michael Thomas wrote: It seems that there really ought to be a better way here to manage my home network. Like, for example, the ability to get stats from router and tell it to shape various devices/flows to play nice. Right now, it seems to me that the state of the art is pretty bad -- static-y kinds of setups for static-y kinds of flows that people-y kind of users don't understand or touch on their home routers. I've been using per-connection queues on a Mikrotik 450G; this permits shaping based on the destination/source IP, so no one device can nom all of the bandwidth on the link unless it's uncontested; should more than one device want all the bandwidth they both get half, and so on (in a typical config). It's not flawless but it's a massive improvement on no shaping whatsoever. The gotcha is that you need to configure your link speed in the router for it to be aware of the capacity it has to play with, but that's not something you have to touch very often most of the time (though if your connection speed/upstream capacity varies, there's not a lot that'll help you at that point. But it does most of the time stop the X is watching HD YouTube videos and now I can't check my email sort of problems. It's a nice set-and-forget solution. ntop or similar on a Linux boxen in concert with flows from said Mikrotik tends to help more than anything for analysis of usage etc, but it's still an inelelegant solution to the problem of analyzing links in this scenario. I'd be interested in what other people are using for home connection debugging. Cheers, James -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlEa2esACgkQ22kkGnnJQAyFnwCfcaq95/Nd1iNk4Fj/j6jSB98A fEsAn3CIgoizBZjPbTTwlQPS+iKccx2Q =FUhz -END PGP SIGNATURE-
Re: home network monitoring and shaping
I've had great luck with Cisco's fair-queue option (and similar techniques). Using RED, small queues (think on the order of 10-20 packets), and creating a choke point in and out of the network, I've implemented similar behavior on plenty of DSL lines on the CPE-side. My most successful was sharing one 7mbps line with 120 technical employees - before the implementation of improved queuing, web pages took 60 seconds or more to load during peak usage. After implementation, people didn't know they were on a shared DSL unless they tried streaming video (fortunately not a business requirement) or a bulk download (it worked fine, it just would be slow if there were several others going on at the same time). I suspect I could have even made a VoIP call across the line with a MOS in the high 3's easily. A second issue is poor wireless retransmission and buffering implementations in consumer wireless. For my home, to make VoIP work with low-end gear, I had to break most HTTP sessions and switch to a delay-based congestion control algorithm inside my network - due to the 5+ second buffers on the wifi gear. That would probably have been enough, but turning on WMM really took the rest of the pain out of wifi-VoIP. I don't know how to fix the home wifi problems (WMM helps with some applications, certainly, but it's not a full solution if you still have 5 second buffers in the default traffic class). But for the other problems, it would be nice if my provider didn't give me huge buffers and no RED on the output queue (I have no idea if they are doing the best they can with the gear they have or not, so there may not be any option here). But, even without that, home routers can do better than they do now. My router knows what speed it's connected at. It can create an internal bottleneck slightly slower, prioritize small packets, implement RED, and use reasonably-sized buffers (fast downloads should not increase ping times by hundreds of ms). I shouldn't need to hang a Linux box between it and my home network. Large buffers have broken the average home internet. I can't tell you how many people are astonished when I say one of your family members downloading a huge Microsoft ISO image (via TCP or other congestion-aware algorithm) shouldn't even be noticed by another family member doing web browsing. If it is noticed, the network is broke. Even if it's at the end of a slow DSL line.
Re: home network monitoring and shaping
On 2/12/2013 4:10 PM, James Harrison wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2013 21:56, Michael Thomas wrote: It seems that there really ought to be a better way here to manage my home network. Like, for example, the ability to get stats from router and tell it to shape various devices/flows to play nice. Right now, it seems to me that the state of the art is pretty bad -- static-y kinds of setups for static-y kinds of flows that people-y kind of users don't understand or touch on their home routers. I've been using per-connection queues on a Mikrotik 450G; this permits shaping based on the destination/source IP, so no one device can nom all of the bandwidth on the link unless it's uncontested; should more than one device want all the bandwidth they both get half, and so on (in a typical config). It's not flawless but it's a massive improvement on no shaping whatsoever. The gotcha is that you need to configure your link speed in the router for it to be aware of the capacity it has to play with, but that's not something you have to touch very often most of the time (though if your connection speed/upstream capacity varies, there's not a lot that'll help you at that point. But it does most of the time stop the X is watching HD YouTube videos and now I can't check my email sort of problems. It's a nice set-and-forget solution. ntop or similar on a Linux boxen in concert with flows from said Mikrotik tends to help more than anything for analysis of usage etc, but it's still an inelelegant solution to the problem of analyzing links in this scenario. I'd be interested in what other people are using for home connection debugging. Cheers, James For Mikrotik routers, use the Winbox application and the Torch function on the interface. You can set it to show flows by various criteria such as source IP. That will tell you which client is chewing up the bandwidth at any instant. Another way to go that I have not tried with Mikrotik is the Solarwinds Netflow analyzer. It tracks 60 minutes of data. http://www.solarwinds.com/products/freetools/netflow_analyzer.aspx
Re: home network monitoring and shaping
I vote pfSense.. don't skimp on the NIC's when you build one out (Intel ftw). My $0.02.. Gino On 2/12/13 1:56 PM, Michael Thomas wrote: O oracle of nanog: unlike things like rogue processes eating tons of CPU, it seems to me that network monitoring is essentially a black art for the average schmuck home network operator (of which I count myself). That is: if the network is slow, it's really hard to tell why that might be and who of the eleventy seven devices on my wifi is sucking the life out of my bandwidth. And then even if I get an idea of who the perp is, my remediation choice seems to be find that device, smash it with sledge hammer. It seems that there really ought to be a better way here to manage my home network. Like, for example, the ability to get stats from router and tell it to shape various devices/flows to play nice. Right now, it seems to me that the state of the art is pretty bad -- static-y kinds of setups for static-y kinds of flows that people-y kind of users don't understand or touch on their home routers. The ob-nanog is that my intertoobs r slow is most likely a call to your support desks which is expensive, of course. Is anything happening on this front? Is openwrt, for example, paying much attention to this problem? Mike
Re: home network monitoring and shaping
I'd be interested in what other people are using for home connection debugging. I put the teenager behind a 10Mb hub haven't had any problems since :) Regards, Lee On 2/12/13, James Harrison ja...@talkunafraid.co.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2013 21:56, Michael Thomas wrote: It seems that there really ought to be a better way here to manage my home network. Like, for example, the ability to get stats from router and tell it to shape various devices/flows to play nice. Right now, it seems to me that the state of the art is pretty bad -- static-y kinds of setups for static-y kinds of flows that people-y kind of users don't understand or touch on their home routers. I've been using per-connection queues on a Mikrotik 450G; this permits shaping based on the destination/source IP, so no one device can nom all of the bandwidth on the link unless it's uncontested; should more than one device want all the bandwidth they both get half, and so on (in a typical config). It's not flawless but it's a massive improvement on no shaping whatsoever. The gotcha is that you need to configure your link speed in the router for it to be aware of the capacity it has to play with, but that's not something you have to touch very often most of the time (though if your connection speed/upstream capacity varies, there's not a lot that'll help you at that point. But it does most of the time stop the X is watching HD YouTube videos and now I can't check my email sort of problems. It's a nice set-and-forget solution. ntop or similar on a Linux boxen in concert with flows from said Mikrotik tends to help more than anything for analysis of usage etc, but it's still an inelelegant solution to the problem of analyzing links in this scenario. I'd be interested in what other people are using for home connection debugging. Cheers, James -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlEa2esACgkQ22kkGnnJQAyFnwCfcaq95/Nd1iNk4Fj/j6jSB98A fEsAn3CIgoizBZjPbTTwlQPS+iKccx2Q =FUhz -END PGP SIGNATURE-
Re: IPv6 support by wifi systems
On Tue, 2013-02-12 at 16:29 -0500, Brandon Ross wrote: It seems that, then, MLD snooping is valuable as it will prevent DAD and other ND traffic from using bandwidth towards hosts not in that group. It will prevent *all* multicast traffic from using bandwidth towards hosts not in the multicast groups involved. ND, DAD etc are just specific cases. Other than solicited node multicast, is MLD used anywhere else in a network that does not have layer 3 multicast enabled on a router? MLD is used for all multicast - so a DHCPv6 packet, for example, will only go to any relays and servers in the subnet. *Any* multicast will be limited to its listeners. The only multicast that will go to all nodes will be multicast sent to the all link-local nodes address - and even that will not go to non-IPv6 nodes. MLD snooping happens on switches - you will get the benefit even if in an isolated network (no router at all). Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
