If I am not mistaken the IETF efforts to standardize the TRILL spec, and IEEE efforts to standardize the DCB spec will provide the desired features to Ethernet: lossless delivery, QoS, and bringing an IS-IS layer 3 model to layer 2. I think Cisco has a pre TRILL/DCB standards feature set called Fabricpath, and Brocade has a feature set called VCS. Both, I think, will converge Ethernet data and Fibre Channel over the same wire. -----Original Message----- From: Tom Hill [mailto:tom@ninjabadger.net] Sent: Thursday, December 29, 2011 11:58 AM To: nanog@nanog.org Subject: Re: next-best-transport! down with ethernet! On Thu, 2011-12-29 at 10:06 -0500, Christopher Morrow wrote:

yes, let's get something with say fixed sized packets, ability to have predictable jitter and also, for fun, no more STP! Ethernet is too complex, maybe something simpler? I hear there's this new tech 'ATM'? it seems to fit the bill!

Pfft. Everyone knows that Fibre Channel's going to replace everything... The minute we get those 128Gbit/sec transmission characteristics, Ethernet's gonna be as good as RS-485. This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.

I am php/javascript programmer. The web used to be request/reply. With the request small (but not small enough), and the reply long. But the time for permanent connections is comming. Links from clients to server that are permanent. Or look like that in the application layer. On one sense, this is a optimization, no more pooling the server "do you have something for me?" every n seconds. But I imagine mostly make things like caching and proxies pointless. At some point, users will start getting unhappy with web pages replies slower than 100 ms. ATM my webpages takes longer to start Jquery that all the server-client interactions. Most obvious optimization is never reload the page, and run everything trough ajax calls. I am not dumb, I know turning webpages into applications make webpages to fragile. But I am scared of javascripts. Javascript is just too dawmn usefull now, browsers too broken (mostly IE), and Javascript is like a superhero that fix all. The web is going to change in a few years, from a "request" "reply" interchange network, to something more like a computer "bus". I don't know how the "wires" will react to this. On 30 December 2011 10:58, Vitkovsky, Adam <avitkovsky@emea.att.com> wrote:

Actually an a Cisco presentation on Nexus 7k I asked whether it's possible to transport the FCoE over let's say EoMPLS or VPLS and did not get a straight answer though that was half a year ago -but it would be really cool to connect hard-drives directly over continents

adam

-----Original Message----- From: Tom Hill [mailto:tom@ninjabadger.net] Sent: Thursday, December 29, 2011 8:58 PM To: nanog@nanog.org Subject: Re: next-best-transport! down with ethernet!

On Thu, 2011-12-29 at 10:06 -0500, Christopher Morrow wrote:

...

yes, let's get something with say fixed sized packets, ability to have predictable jitter and also, for fun, no more STP! Ethernet is too complex, maybe something simpler? I hear there's this new tech 'ATM'? it seems to fit the bill!

Pfft. Everyone knows that Fibre Channel's going to replace everything... The minute we get those 128Gbit/sec transmission characteristics, Ethernet's gonna be as good as RS-485.

-- -- ℱin del ℳensaje.

Well hopefully we won't need to worry about the speed of light anymore Just recently I heard about the experiments with "quantum nonlocality" no one seem to understand how it happens but for me it's enough it works Basically when 2 photons or electrons are emitted form the same source -they are somehow bound/entangled together -that means if we change the spin on one photon to "up" the other photon will have it's spin changed to "down" immediately -and it doesn't matter whether the photons are next to each other or light years away -this happens instantly (no energy is transferred yet the information is passed) -this was already tested between two cities Imagine that instead of sfp connectors and dark fiber between San Fran and NY node we'd install a connectors with let's say 1500k entangled photons -and if we set the spin in a way to send a 1500kbit packet to NY the NY node would see it instantly -no cables needed -also there some attempts to actually send the information 50 micro sec back in time Of course there are still these issues with probabilities at quantum level adam

What we really need is a new method of sending data. The fact that I will never be able to send something from Maine to California in less than 15 ms is not acceptable.

The speed of light is such a drag.

http://en.wikipedia.org/wiki/No-communication_theorem -- Aiden On Dec 30 14:00, Vitkovsky, Adam wrote:

Well hopefully we won't need to worry about the speed of light anymore

Just recently I heard about the experiments with "quantum nonlocality" no one seem to understand how it happens but for me it's enough it works

Basically when 2 photons or electrons are emitted form the same source -they are somehow bound/entangled together -that means if we change the spin on one photon to "up" the other photon will have it's spin changed to "down" immediately -and it doesn't matter whether the photons are next to each other or light years away -this happens instantly (no energy is transferred yet the information is passed) -this was already tested between two cities

Imagine that instead of sfp connectors and dark fiber between San Fran and NY node we'd install a connectors with let's say 1500k entangled photons -and if we set the spin in a way to send a 1500kbit packet to NY the NY node would see it instantly -no cables needed

-also there some attempts to actually send the information 50 micro sec back in time

Of course there are still these issues with probabilities at quantum level

adam

...

What we really need is a new method of sending data. The fact that I will never be able to send something from Maine to California in less than 15 ms is not acceptable.

...

The speed of light is such a drag.

----- Original Message -----

From: "Adam Vitkovsky" <avitkovsky@emea.att.com>

Article by John Cramer says:

At the AQRTP Workshop we considered the question of whether quantum nonlocality was a possible medium for FTL communication. In the context of standard quantum mechanics there is good reason for believing that it is not. Eberhard has proved a theorem demonstrating that the outcomes of separated measurements of the same quantum system, correlated by nonlocality though they are, cannot be used for FTL observer-to-observer communication. A possible loophole in Eberhard's theorem could arise if, following the work of Nobel Laureate Steven Weinberg, one modifies conventional quantum mechanics by introducing a small non-linear element into the standard QM formalism. It has been shown that in slightly non-linear quantum mechanics, the observable nonlinear effects that would arise would make possible FTL communication through nonlocality.

Wasn't this covered in an RFC I read, dated 1 April 2030? Cheers, -- jra -- Jay R. Ashworth Baylink jra@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

On Fri, 30 Dec 2011 11:40:35 PST, Vadim Antonov said:

faster than the speed of light. (The reality of FTL neutrino thingie is still too early to tell).

Especially if you actually *read* the actual journal article rather than the pop-sci interpretation of it, it basically says "our experiment had the neutrinos showing up 60ns faster than lightspeed - we can't find what we did wrong, does anybody else see what we screwed up?" - i.e. an appeal to "with enough eyeballs, all bugs are shallow". (Personally, I'm betting on a mascon somewhere in northern Italy distorting the actual path taken so the actual geodesic isn't what they thought it was..)

----- Original Message -----

From: "Robert Bonomi" <bonomi@mail.r-bonomi.com>

...

Of course there are still these issues with probabilities at quantum level

I *strongy* recommend that anyone pursuing this subject read Dr. Asimov's essays on resublimated thiotimoline.

As well as Spider Robinson's codicil... Cheers, -- jra -- Jay R. Ashworth Baylink jra@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

On Fri, Dec 30, 2011 at 7:24 AM, Ray Soucy <rps@maine.edu> wrote:

What we really need is a new method of sending data.  The fact that I will never be able to send something from Maine to California in less than 15 ms is not acceptable.

The speed of light is such a drag.

I propose that everyone on this mailing list make it their #1 New Years Resolution to fix this problem. If we all work together, we can do something about it! Tom -- http://EverythingSysadmin.com  -- my blog http://www.TomOnTime.com -- my videos

On Dec 30, 2011, at 6:01 AM, Tei wrote:

I am not dumb, I know turning webpages into applications make webpages to fragile. But I am scared of javascripts. Javascript is just too dawmn usefull now, browsers too broken (mostly IE), and Javascript is like a superhero that fix all. The web is going to change in a few years, from a "request" "reply" interchange network, to something more like a computer "bus". I don't know how the "wires" will react to this.

I think the challenge here is going to be the unintended interactions of the subsystems involved. Take a look at the buffer bloat research and activities. I think getting a better symmetric speed ratio to the edge will help solve this problem. Just because you have 22:5 capability at home, or 50:10 (5:1) doesn't mean it will be used that way, but being closer to 2:1 will likely cause some significant improvements in performance. The internet as the transport over the top of the physical {fiber,copper,coax} is going to continue to grow. The folks at NTT just announced their 60th 10G across the pacific. With the continued growth here and 100G out there, handling the traffic will certainly become interesting. I think the dark buffers are going to be the biggest challenge we see. (I'm hoping for some good snow storms in the midwest/north east/NoVA area to put some good stresses on the network for a week or so this winter that can be measured/observed). - Jared

On Friday, December 30, 2011 05:58:38 PM Vitkovsky, Adam wrote:

Actually an a Cisco presentation on Nexus 7k I asked whether it's possible to transport the FCoE over let's say EoMPLS or VPLS and did not get a straight answer though that was half a year ago -but it would be really cool to connect hard-drives directly over continents

We looked at doing this back in 2010, and the problems are still the same - synchronous replications (which is the majority of your garden-variety fibre channel deployments) are very sensitive to latency and low bandwidth, and don't generally tend to exist outside the data centre or short- distance DWDM fibre channel networks. FCIP was the solution proposed for extending SAN's over IP (which invariably means over MPLS as well). But FCIP tends to work best with asynchronous replications, which is the only way to get around higher latency and lower bandwidth network properties. I know Brocade and Cisco both have boxes that support FCIP. I did come across a vendor, Orckit-Corrigent - http://www.orckit.com/ - that claimed they support FCoMPLS (I forget what their exact solution was, but it had to do with some buffering trickery if memory serves), but we didn't get a chance to test these as FCoDWDM ending up winning anyway. Come to think of it, maybe their solution was FCIP inside MPLS :-). Cheers, Mark.

On Thu, Dec 29, 2011 at 19:11, Randy Bush <randy@psg.com> wrote:

atm-2, aka mpls

I knew MPLS was fishy... -- Darius Jahandarie