Four Lit-tle Bytes (an IPv4 song)
This is a song I've been working on on and off over the last couple years; when I sang it recently at a filk convention, I was told I should post it here. I hope it’s not too OT (or too technically inaccurate!). Sheet music, MIDI, and ABC source are available at http://songs.q-ist.com/. Four Lit-tle Bytes of Ad-dress Code by Aaron Davies ttto “Two Lit-tle Bytes” by Amy Fass after “Three Little Maids from School” by Gilbert & Sullivan chorus: Four little bytes of address code Couldn’t spare any more bandwidth load To indicate the network node Four little bytes of code Four little bytes, all allocated IPv6 is anticipated Sixteen years we’ve already waited! Four little bytes of code (chorus) Four little bytes, a space all used up Fridges and toasters IPs have chewed up When will the ISPs get clued-up? Four little bytes of code (chorus) Four little bytes, a space exhausted Plenty of room, once, but now we’ve lost it v4 is dead, man, it’s time we tossed it[1] Four little bytes of code Four little by———tes of code! Save on your subnets—four bytes! END [1] Thanks to Bob Kanefsky for the rhyme! -- Aaron Davies aaron.dav...@gmail.com
Re: Most energy efficient (home) setup
On Apr 18, 2012, at 5:55 32PM, Douglas Otis wrote: > On 4/18/12 12:35 PM, Jeroen van Aart wrote: >> Laurent GUERBY wrote: >> > Do you have reference to recent papers with experimental data about >> > non ECC memory errors? It should be fairly easy to do >> Maybe this provides some information: >> >> http://en.wikipedia.org/wiki/ECC_memory#Problem_background >> >> "Work published between 2007 and 2009 showed widely varying error >> rates with over 7 orders of magnitude difference, ranging from >> 10−10−10−17 error/bit·h, roughly one bit error, per hour, per >> gigabyte of memory to one bit error, per century, per gigabyte of >> memory.[2][4][5] A very large-scale study based on Google's very >> large number of servers was presented at the >> SIGMETRICS/Performance’09 conference.[4] The actual error rate found >> was several orders of magnitude higher than previous small-scale or >> laboratory studies, with 25,000 to 70,000 errors per billion device >> hours per megabit (about 3–10×10−9 error/bit·h), and more than 8% of >> DIMM memory modules affected by errors per year." > Dear Jeroen, > > In the work that led up to RFC3309, many of the errors found on the Internet > pertained to single interface bits, and not single data bits. Working at a > large chip manufacturer that removed internal memory error detection to > foolishly save space, cost them dearly in then needing to do far more > exhaustive four corner testing. Checksums used by TCP and UDP are able to > detect single bit data errors, but may miss as much as 2% of single interface > bit errors. It would be surprising to find memory designs lacking internal > error detection logic. mallet:~ smb$ head -14 doc/ietf/rfc/rfc3309.txt | sed 1,7d | sed 2,5d; date Request for Comments: 3309 Stanford September 2002 Wed Apr 18 23:07:53 EDT 2012 We are not in a static field... (3309 is one of my favorite RFCs -- but the specific findings (errors happen more often than you think), as opposed the general lesson (understand your threat model) may be OBE. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: Comcast Admin
Looks like this issue has been resolved. We are waiting for a post-mortem to figure out what the issue was but thanks everyone for looking into this. On 4/18/12 3:41 PM, John Neiberger wrote: On Wed, Apr 18, 2012 at 1:24 PM, chk wrote: We are having issues with one of our sites being blocked for Comcast home users and going the normal channels is not working. If there is anyone that can contact me off list to get this resolved I would appreciate it. I'm not sure who the right channels would be, but I'm asking around to see if I can find the right people to help you resolve this quickly. I'll let you know what I find out. John
Re: Comcast Admin
On Wed, Apr 18, 2012 at 1:24 PM, chk wrote: > We are having issues with one of our sites being blocked for Comcast home > users and going the normal channels is not working. If there is anyone that > can contact me off list to get this resolved I would appreciate it. > I'm not sure who the right channels would be, but I'm asking around to see if I can find the right people to help you resolve this quickly. I'll let you know what I find out. John
Re: Most energy efficient (home) setup
On 4/18/12 12:35 PM, Jeroen van Aart wrote: Laurent GUERBY wrote: > Do you have reference to recent papers with experimental data about > non ECC memory errors? It should be fairly easy to do Maybe this provides some information: http://en.wikipedia.org/wiki/ECC_memory#Problem_background "Work published between 2007 and 2009 showed widely varying error rates with over 7 orders of magnitude difference, ranging from 10−10−10−17 error/bit·h, roughly one bit error, per hour, per gigabyte of memory to one bit error, per century, per gigabyte of memory.[2][4][5] A very large-scale study based on Google's very large number of servers was presented at the SIGMETRICS/Performance’09 conference.[4] The actual error rate found was several orders of magnitude higher than previous small-scale or laboratory studies, with 25,000 to 70,000 errors per billion device hours per megabit (about 3–10×10−9 error/bit·h), and more than 8% of DIMM memory modules affected by errors per year." Dear Jeroen, In the work that led up to RFC3309, many of the errors found on the Internet pertained to single interface bits, and not single data bits. Working at a large chip manufacturer that removed internal memory error detection to foolishly save space, cost them dearly in then needing to do far more exhaustive four corner testing. Checksums used by TCP and UDP are able to detect single bit data errors, but may miss as much as 2% of single interface bit errors. It would be surprising to find memory designs lacking internal error detection logic. Regards, Douglas Otis
Re: letter opposing cybersecurity legislation: looking for signers
Thanks to everyone who has responded so far, and apologies for the terrible formatting of the actual letter. Just a reminder to let me know by tomorrow morning if you would be interesting in signing -- if you've replied to me already, no need to do so again, I will respond to you tomorrow. Also, if anyone has good leads about large mailing lists that might be a good place to solicit professionals, academics, or security experts, please let me know as soon as possible. And feel free to circulate this request yourself to colleagues, and tell them to email me. We are aiming to get the letter together by Thursday or Friday, but have yet to determine the exact time line for publication. On 04/17/2012 06:02 PM, Dan Auerbach wrote: > Dear NANOGers, > > EFF is looking for sign-ons to a letter expressing concern about some of the > proposed "cybersecurity" legislation currently being debated in the US > Congress. This legislation has a number of alarming provisions, including > incentives for recording massive amounts of network traffic and sharing it > with federal agencies; nullification of existing wiretapping and privacy > laws; in some cases, new kinds of bureaucracy for backbone and other ISPs who > are designated as "critical infrastructure", and provisions that establish > intellectual property enforcement as a "cybersecurity" objective. > > We realize this is potentially a complicated topic in the NANOG community, > and we'd prefer not to start a giant OT flamewar, so: if you agree with our > concerns and would like to sign on to our letter, let us know by private > email by Thursday morning 9am Pacific US time. If you think we have the wrong > perspective, you can let us know off-list, or write your own letters, or work > with your various policy departments on this. > > Because there are many "cybersecurity" bills currently being debated in the > US House and Senate, the letter is generally framed in opposition to bad > aspects of the bills, though it calls out two current proposals that are > particularly bad and close to passing: CISPA (H.R. 3523) in the House, and > "Secure IT Act" (S. 2151) in the Senate. The letter also is intended to be > simple and focused on the civil liberties issues that stem from the broadness > of the bills. It does not talk about technical problems with deploying > IDS/IPS in the private sector (for a discussion of this, see, e.g. > http://harvardnsj.org/wp-content/uploads/2012/01/Vol.-3_Bellovin_Bradner_Diffie_Landau_Rexford1.pdf) > or other legitimate technical concerns about effectiveness. We certainly > encourage people to raise these concerns separately. The text of the letter > is below in triple quotes: > > """ > > Dear Lawmakers, > > > We are writing you today as professionals, academics, and experts who > have researched, analyzed, and defended against security threats to the > Internet and its infrastructure. We have devoted our careers to building > security technologies, and to protecting networks, computers, and > critical infrastructure against attacks of many stripes. > > We take security very seriously, but we fervently believe that strong > computer and network security does not require Internet users to > sacrifice their privacy and civil liberties. The opposite, in fact, is true. > > The bills currently under consideration, including Rep. Rogers' /Cyber > Intelligence Sharing and Protection Act of 2011 /(H.R. 3523) and Sen. > McCain's/SECURE IT Act /(S. 2151)/, /are drafted to allow entities who > participate in relaying or receiving Internet traffic to freely monitor > and redistribute those network communications. The bills nullify current > legal protections against wiretapping and similar civil liberties > violations for that kind of broad data sharing. By encouraging the > transfer of users' private communications to US Federal agencies, and > lacking any form of public accountability or transparency, these > "cybersecurity" bills falsely trade our civil liberties for the promise > of improved network security. As experts in the field, we reject this > false trade-off and urge you to oppose any cybersecurity initiative that > does not explicitly include appropriate methods to ensure the protection > of users' civil liberties. > > In summary, we urge you to reject legislation that: > > * > > Uses vague language to describe network security attacks, threat > indicators, and countermeasures, allowing for the possibility that > innocuous online activities could be construed as "cybersecurity" > threats. > > * > > Exempts "cybersecurity" activities from existing laws that protect > individuals' privacy and devices, such as the Wiretap Act, the > Stored Communications Act, and the Computer Fraud and Abuse Act. > > * > > Gives sweeping immunity from liability to companies even if they > violate individuals' privacy without good reason. > > * > > Allows data originally collected through
Re: Comcast Admin
Usually if you make a jab at Comcast in a joke, by saying ___, this guy will respond shortly. I'll look him up and contact you offlist -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton
Re: Most energy efficient (home) setup
Laurent GUERBY wrote: Do you have reference to recent papers with experimental data about non ECC memory errors? It should be fairly easy to do Maybe this provides some information: http://en.wikipedia.org/wiki/ECC_memory#Problem_background "Work published between 2007 and 2009 showed widely varying error rates with over 7 orders of magnitude difference, ranging from 10−10−10−17 error/bit·h, roughly one bit error, per hour, per gigabyte of memory to one bit error, per century, per gigabyte of memory.[2][4][5] A very large-scale study based on Google's very large number of servers was presented at the SIGMETRICS/Performance’09 conference.[4] The actual error rate found was several orders of magnitude higher than previous small-scale or laboratory studies, with 25,000 to 70,000 errors per billion device hours per megabit (about 3–10×10−9 error/bit·h), and more than 8% of DIMM memory modules affected by errors per year." -- Earthquake Magnitude: 4.9 Date: Wednesday, April 18, 2012 16:21:41 UTC Location: Solomon Islands Latitude: -7.4630; Longitude: 156.7916 Depth: 414.30 km
Re: any sites about interent networkissue
Deric Kwok wrote: Any websites can provide about network issue http://www.internettrafficreport.com/
Comcast Admin
We are having issues with one of our sites being blocked for Comcast home users and going the normal channels is not working. If there is anyone that can contact me off list to get this resolved I would appreciate it.
Re: any sites about interent networkissue
> On Apr 18, 2012 5:43 PM, "Deric Kwok" wrote: >> Any websites can provide about network issue http://www.outages.org/index.php/Dashboard -- Chris Stone AxisInternet, Inc. www.axint.net
Re: any sites about interent networkissue
Are you sure you didn't just mis-type the URL? ;) On Apr 18, 2012 5:43 PM, "Deric Kwok" wrote: > Hi > > Yesterday I have internet nework issue. I checked our interent > providers but their answers are fine > > But the traceroute can't reach to some desintations. eg: gogle > and stopped somewhere > > Any websites can provide about network issue > > Thank you > >
any sites about interent networkissue
Hi Yesterday I have internet nework issue. I checked our interent providers but their answers are fine But the traceroute can't reach to some desintations. eg: gogle and stopped somewhere Any websites can provide about network issue Thank you
How to xconnect in 111 8th NYC
Hello, We are trying to connect our carrier in 111 8th NYC. Our carrier is located in Zayo space and we are located in Telx space. We already have our panel to Telx MMR and have a bunch of position available. Our carrier seems to be unable to connect from Zayo MMR to Telx MMR and it seems to be very complicated to both Telx and Zayo to give a real answer. The last time we had to do it, it was half xconnect to the MMR ( telx ) and the other part was Zayo to our carrier. Now, the carrier have to connect to us ( xconnect included in the price) but ZAYO claims more $$$ ( about twice the price of the other way ) and this is exactly the same path !!! So how does it work really in this building ? Honestly, telx and Zayo are doing this for year and each time it's like they are discovering the wheel ( not sure if this expression exist in English). Raphael Maunier Neo Telecoms
