May 2011 - Test - lists.nanog.org

Re: Re Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company
by Brandon Butterworth 26 May '11

26 May '11

> You demonstrate you have no understanding of what the word 'feasable' > means. OK, but we actually did this as a commercial service on analogue TV and we deliver non picture data on digital TV (satellite and terrestrial) today, it's just not USENET data. > One _cannot_ do this with 'modern' digital TV trasmission, because the > _end-to-end_ technolgy does not support it. Apologies for disagreeing, but this is exactly what the modern technology does. Digital TV (ATSC in your case, DVB-T & DVB-S in our case) has a multiplex of a number of independent data streams that can be data, video or audio. That is carried end to end. We do this now with other data - http://en.wikipedia.org/wiki/BBC_Red_Button It'd be trivial for us to display USENET directly to read on your TV or deliver it to the STB ethernet port > OTOH, if the signal originates as a digital stream, while it may be > "possible" to multiplex in an additional data stream, said data stream > will *NOT* survive _intermediate_ transcoding to an analog video stream > before transmission to the end-user. Indeed but that is not a digital TV system. > And, even if the actual digital > stream is delivered to the end-user, a *STANDARD* digital TV receiver has > no means to deliver that 'additional' information to the end-user in any > usableform. Standard DTV PVR with an ethernet port are a few hundred dollars. For the people who would actually receive this the box cost is trivial they just some software. If you have a USB or PCI DTV rx it is trivial to do whatever you like with the data. brandon

3 2

Re: [outages] Level 3 core router in Chicago down?
by Jay Ashworth 26 May '11

26 May '11

----- Original Message ----- > On 5/25/2011 11:25 PM, Brooks Bridges wrote: > > We just lost a bunch of routes out of Chicago over Level 3. > > > > Seems to be dying at edge routers right before their core. > > > > 1. XXXXXXXXXXXXXXX 0.0% 10 0.5 0.4 > > 0.3 0.6 0.1 > Of course, as soon as I hit send, it comes back... Well, thanks for fixin' that, Brooks. Night, now. Cheers, -- jr 'causation? what's that?' a -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

2 1

Re: Re Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company
by Jay Ashworth 26 May '11

26 May '11

----- Original Message ----- > From: "Brandon Butterworth" <brandon(a)rd.bbc.co.uk> > > You demonstrate you have no understanding of what the word > > 'feasable' means. > > OK, but we actually did this as a commercial service on analogue TV and > we deliver non picture data on digital TV (satellite and terrestrial) > today, it's just not USENET data. You demonstrate that you have no understanding of what the words "sneak along" mean. :-) > > One _cannot_ do this with 'modern' digital TV trasmission, because > > the _end-to-end_ technolgy does not support it. > > Apologies for disagreeing, but this is exactly what the modern > technology does. Allow you to sneak in extra data in an otherwise unused place that won't affect anything, and no one will have to deal with, but end viewers will be able to see it anyway? No, we're pretty sure you're wrong there, probably because you're purposely ignoring our *specific* characterization of the thing which was actually done. > Digital TV (ATSC in your case, DVB-T & DVB-S in our case) has a > multiplex of a number of independent data streams that can be data, > video or audio. That is carried end to end. > > We do this now with other data - > > http://en.wikipedia.org/wiki/BBC_Red_Button > > It'd be trivial for us to display USENET directly to read on your TV > or deliver it to the STB ethernet port Sure. But that wasn't what we were *talking* about. > > OTOH, if the signal originates as a digital stream, while it may be > > "possible" to multiplex in an additional data stream, said data > > stream will *NOT* survive _intermediate_ transcoding to an analog video > > stream before transmission to the end-user. > > Indeed but that is not a digital TV system. Nobody said it was, and what's more: we don't care. :-) > > And, even if the actual digital > > stream is delivered to the end-user, a *STANDARD* digital TV > > receiver has > > no means to deliver that 'additional' information to the end-user in > > any usableform. > > Standard DTV PVR with an ethernet port are a few hundred dollars. > > For the people who would actually receive this the box cost is trivial > they just some software. If you have a USB or PCI DTV rx it is trivial > to do whatever you like with the data. You can't really guarantee that random things injected into a transport stream mux at the send end will make it to the receive end; everyone in the transport path very likely thinks they're entitled to pull the separate program streams out and fiddle with them however they like -- Hell: local cablecos *reencode* the local station HD signals to compress them further. So not only are you not making assertions about the same thing we are, there's a very good chance you're incorrect in the general case about the assertion you *are* making. I don't know if my understanding of terrestrial network and satellite broadcasting in the US carries over to the continent, but I'd bet at least the latter does... Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

1 0

AT&T Opti-man Dallas down
by Tim Connolly 26 May '11

26 May '11

The Dallas area had a round of storms go through last night. Looks like this morning's flaming bag on the front porch was AT&T's "OptiMan" metro-E service was down. Can anyone confirm that this was a wide outage and not just a single customer? Any details released?

3 2

Re Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company
by Robert Bonomi 25 May '11

25 May '11

> From brandon(a)rd.bbc.co.uk Wed May 25 04:21:13 2011 > Date: Wed, 25 May 2011 10:19:09 +0100 (BST) > From: Brandon Butterworth <brandon(a)rd.bbc.co.uk> > To: morrowc.lists(a)gmail.com, nanog(a)nanog.org, bonomi(a)mail.r-bonomi.com > Subject: Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any > Other Company > > > > So... would this have been feasible today? given the bandwidth required > > > to send a full feed these days, i suspect likely not, eh? (even if you > > > were able to do it on all 500+ channels in parallel) > > > > On the financial side, it is trivial. > > The opposite, the bits were paid for but unused back then so > financially it was worth using them. In digital tv every bit has a use > and so a cost, hence they are used for more TV channels instead for > parasitic services. You end up competing with TV if you want any > quantity so hard to make viable today. You demonstrate you have no understanding of what the word 'feasable' means. > > On the engineering side, _impossible_. > > The opposite, completely trivial now. FALSE TO FACT. > Digital TV is a mux of a number > of bit streams, some with compressed video others with meta data for > epg, alternate sound, interactive apps etc. Adding another stream to > the mux is trivial, you just have to pay for the bandwidth though as > most are stat muxed it's possible to create room at the expense of the > vbr streams where the video encoders reduce the quality of as result of > back pressure from the stat muxer Obviously, you misunderstood the 'do this' reference of the prior poster. The 'elegence' of the original Stargate scheme was that the data was injected into the original video signal at the oint of origin, passed through _all_ the intermediate points, WITHOUT any special handling (or even 'awareness' that the 'extra' information is there) and delivered to the end-user, where it was extracted by a _standard_ TV receiver to a normal _video_ signal, from which the extra data was then extracted. One _cannot_ do this with 'modern' digital TV trasmission, because the _end-to-end_ technolgy does not support it. *IF* the signal =originates= as an _analog_ video signal, as many of the cable-only channels _still_ do, "data" in the vertical interval is lost at the analog-to-digital conversion, and simply _cannot_ be recovered at the end-user's TV reciever output. OTOH, if the signal originates as a digital stream, while it may be "possible" to multiplex in an additional data stream, said data stream will *NOT* survive _intermediate_ transcoding to an analog video stream before transmission to the end-user. And, even if the actual digital stream is delivered to the end-user, a *STANDARD* digital TV receiver has no means to deliver that 'additional' information to the end-user in any usableform. *GIVEN* the constraints of: 1) injection at the point of video signal origination (-not- the satellite uplink point 2) "transparent" carriage to the end-user viewer of the video signal, 3) end-user extraction of data from the output of a commercial off-the-shelf TV tuner/receiver Now, > > > To pick a conservative number, say you get an effective throughput of > > 2k bytes/sec > > It'd be easy to squeeze that into a normal tv satellite mux Sorry, you've got to squeeze _several_times_ that figure 'into the mux', to provide the 'redundant' transmissions needed to compensate for momentary LOS events. So?? what about the _rest_ of the path the signal goes through to get to the end-user's TV set. The original methodology was -not- about delivering a USENET feed to a satellite receiving station with special eqquipment to extract it, but delivering it _transparently_ (or even 'invisibly' :) ALL THE WAY to the _end-user_ consumer/viewer. > > > As I understand it, a current USENET 'full feed', including binaries, take > > two dedicated 100mbit FDX fast ethernet links, and they are saturated _most_ > > of the day. At that rate, A full day of TV vertical interval transmission > > wuould handle under _ten_seconds_ worth of the inbound traffic. You would > > around =ten=thousand= analog TV channels to handle a contemporary 'full > > feed'. > > Or just 3 full muxes at cost of around 10M (probably the same in any > currency) per year *TRIPLE* that, _at_least_, to allow for automatic multiple transmissions of everything, to avoid 'lost data' due to data errors and/or momentary signal- path obstructions. This is a one-way 'broadcast' link with no ACK/NAK type responses from the receiving end(s) possible. Recurring cost for the sat link, more like 30-50 million/year. Plus the costs _or the dedicated gear at _every_ downlink point. Further, that gets it on the satellite -- "Now What??" applies. _How_ do you get it the proverbial 'last mile' to the end-user consumer? And at what kind of cost for the CPE for _each_ customer? Or are you 'assuming' that some third-party handles that? Don't forget to add the capital cost for all the CPE, _plus_ the MRC for the last-mile distribution to the circa 40 million/year for the 'bare' satellite bandwidth. The value of 'Stargate' was that it delivered a feed to _anyone_ who could get the video signal -- with _zero_ action required by any intermediate third party who was re-transmitting the signal -- in a form that could be extracted with *inexpensive* CPE. There was also an _esisting_ 'standard' for the encoding of data into the video signal, so that the same CPE could be used to extract data from _any_ video source carrying it. And, there _were_ multiple possible video sources. If the local cable company carried a ny of them you were in business. Yes, you *CAN* engineer a "completely different" methodology for delivering a full USENET feed to end-users via satellite transmission. However, doing so is contrary to the premise of the existing discussion.

2 1

Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company
by Roy 25 May '11

25 May '11

http://e.businessinsider.com/public/184962

35 58

Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company
by Brandon Butterworth 25 May '11

25 May '11

> > So... would this have been feasible today? given the bandwidth required > > to send a full feed these days, i suspect likely not, eh? (even if you > > were able to do it on all 500+ channels in parallel) > > On the financial side, it is trivial. The opposite, the bits were paid for but unused back then so financially it was worth using them. In digital tv every bit has a use and so a cost, hence they are used for more TV channels instead for parasitic services. You end up competing with TV if you want any quantity so hard to make viable today. > On the engineering side, _impossible_. The opposite, completely trivial now. Digital TV is a mux of a number of bit streams, some with compressed video others with meta data for epg, alternate sound, interactive apps etc. Adding another stream to the mux is trivial, you just have to pay for the bandwidth though as most are stat muxed it's possible to create room at the expense of the vbr streams where the video encoders reduce the quality of as result of back pressure from the stat muxer > To pick a conservative number, say you get an effective throughput of > 2k bytes/sec It'd be easy to squeeze that into a normal tv satellite mux > As I understand it, a current USENET 'full feed', including binaries, take > two dedicated 100mbit FDX fast ethernet links, and they are saturated _most_ > of the day. At that rate, A full day of TV vertical interval transmission > wuould handle under _ten_seconds_ worth of the inbound traffic. You would > around =ten=thousand= analog TV channels to handle a contemporary 'full > feed'. Or just 3 full muxes at cost of around 10M (probably the same in any currency) per year brandon

2 1

Re: Rogers Canada using 7.0.0.0/8 for internal address space
by Scott Weeks 25 May '11

25 May '11

--- wavetossed(a)googlemail.com wrote: So we should CONDONE such borrowing and recommend a couple of /8s to use in North America. Perhaps one could be DOD for those operators ---------------------------------------- Yes, so it turns IPv4 into such a big steaming pile that every one goes to IPv6 to "get clean" and get their lives back from all the ugly IPv4 troubleshooting. >;-) <== evil grin scott

1 0

EAP-SIM authentication for WiFi networks
by Rogelio 24 May '11

24 May '11

Can anyone share a working model / solution for EAP-SIM authenticated smart phones on Wi-Fi networks? (Or even EAP-AKA?) i.e. instead of having to login a portal with a user / password or pre-authenticate MAC addresses, have it be seemless if they are already a subscriber. AT&T does this with the WISPr client on the iPhones, but I was hoping for something that worked across the board with Android devices for a given carrier. Any suggestions here on who I might talk to? -- Also on LinkedIn? Feel free to connect if you too are an open networker: scubacuda(a)gmail.com

2 1

HIJACKED: AS18466, courtesy of Global Crossing (AS3549)
by Ronald F. Guilmette 24 May '11

24 May '11

Abundant evidence indicates that AS18466, allocated by LACNIC, has been hijacked. All of the routes currently announced by this AS, i.e.: 170.25.0.0/19 170.25.32.0/19 170.25.160.0/19 170.25.192.0/19 are currently routing IP blocks, also allocated by LACNIC, which have also themselves appear to have been hijacked. As you can see below, AS18466 was first allocated (apparently by ARIN) on 2000-08-31 and its WHOIS record was last updated on 2006-06-16. Note however that the domain associated with the contact e-mail address for this ASN, i.e. "geminicom.net" was apparently re-registered on 2010-11-01, unboubtedly by the hijacker. (This is the mostly commonly used approach to AS and IP block hijacking, i.e. find an abandoned AS or IP block whose contact domain has become unregistered and then simply re-register it and then pretend that you are the original party to whom the resource was allocated. In short, fraud and identity theft.) ========================================================================= aut-num: AS18466 owner: Geminicommunications Limited ownerid: BZ-GELI-LACNIC address: 13 1/2 Northern Highway address: Belize City, country: BZ owner-c: HC170-ARIN created: 20000831 changed: 20060616 source: ARIN-HISTORIC nic-hdl: HC170-ARIN person: Hans Cardenas e-mail: hcardenas(a)GEMINICOM.NET address: 13 1/2 Northern Highway address: Belize City, country: BZ phone: 501254011 source: ARIN-HISTORIC ========================================================================= As shown here: http://www.robtex.com/as/as18466.html#graph AS18466 is connected to the Internet only via Global Crossing. In my opinion, and based on the available evidence, there appear to me to be only two possibilities. Either (1) Global Crossing is consciously and in- tentionally participating in this fraud and identity theft scheme or else (2) Global Crossing has allowed itself to be hoodwinked by crooks who con- vinced one or more decision makers at Global Crossing to allow fradulent route announcements to pass to the wider Internet via Global Crossing's network. I look forward to Global Crossing's clarification of this event. Additional evidence of this hijacking may be found here: ftp://ftp.tristatelogic.com/pub/AS18466-rDNS.txt and also here: ftp://ftp.tristatelogic.com/pub/AS18466-nameservers.txt Both of these files show an abundance of "snowshoe" spamming domains which are associated with the IPv4 space currently routed by AS18466. All of these domains have been registered in the relatively recent past, and all of them have been registered either with WHOIS anonymity cloaking or with clearly fradulent WHOIS information. Additional supporting evidence of this hijacking is also readily available in teh form of the following fradulent web site: http://geminicom.net/ This false front web site, intended to serve as part of the clever deception surrounding the miraculous rebirth of "Geminicommunications Limited", is in fact nothing more than a thin veneer, much of which appears to have been simply stolen/copied from the web site of a legitimate UK company, i.e. http://www.8el.com/ (That copying itself represents yet another fradulent and illegal act, i.e. blatant copyright violation.) As was true with the prior group of IP hijackings that I reported on back on April 14th[1], in this case also the majority of the snowshoe spamming domains involved in this incident (as shown in the AS18466-rDNS.txt file, see above) have been registered via the ICANN accredited registrar named Dynamic Dolphin, Inc. It is, I believe, well and widely know by this time that Dynamic Dolphin, Inc. is among the past and/or present business interests of the notorious Scott Richter, interests which include, or which have included bulk e-mail advertising firm Media Breakaway LLC, aka OptInRealBig. Other evidence I have in hand also indicates a clear connection between this hijacked IP space and another of Richter's business interests, specifically a company called WholesaleBandwidth, Inc. (I am not dis- closing this additional evidence publically at the present time. I have my reasons.) FULL DISCLOSURE: Previously, in 2005, my company filed a legal claim in the bankruptcy proceeding of Media Breakaway LLC, said bankruptcy having been largely if not entirely precipitated by a multi-million dollar legal action initiated by Microsoft against Media Breakaway LLC and Scott Richter personally for various alleged mass violations of various anti-spam laws. My company's claim was subsequently dismissed by the bankruptcy judge in that case (improperly, in my view) and following the later dismissal of the bankruptcy case, the Richters (Scott and father Steve) sued myself, my company, and my attorney for alleged "abuse of process", specifically for having had the gumption to show up in the bankruptcy case and make a claim not too awfully different from the one that Microsoft had made. The Richter's "abuse of process" case against me, my company, and my attorney was also subsequently dismissed, the judge having found it to be lacking in merit. Regards, rfg P.S. Those of you who missed it the first time around may wish to review the following potentially relevant historical reference material: http://www.47-usc-230c2.org/chapter2.html http://www.47-usc-230c2.org/chapter3.html P.P.S. Although I have previously bemoaned ARIN's lack of agressivness in reclaiming abandoned ASNs and IP blocks that have been hijacked, I feel compelled to note that at least they (ARIN) do have a proccess in place for doing so, i.e. when and if they are motivated in that direction. I have it on good authority however that LACNIC does not even have an established process for reclaiming abandoned number resources. Given that the problem of hijacked number resources, rather than disappearing, is in fact accelerating, over time, I do believe that it would behove LACNIC and other RiRs to develop processes for reclaiming abandoned resources, in particular when and where it becomes evident that these resources have been hijacked. =-=-=-=-= [1] See http://mailman.nanog.org/pipermail/nanog/2011-April/035235.html

2 1