On Tue, Aug 07, 2012 at 05:15:51PM -1000, Michael Painter wrote:
Eugen Leitl wrote:
http://www.wired.com/business/2012/08/ff_wallstreet_trading/all/
Some interesting, network-relevant content there (but for the
neutrino and drone rubbish).
'Rubbish' might be a pretty strong word when you're
On Tue, Aug 7, 2012 at 4:12 PM, Jim Ray j...@neuse.net wrote:
Sorry, I do not give verbose responses via iPhone on that small device
with my tired old eyes. I ran Wireshark this morning.
Without sniffing packets, the layman's description of problem is I
can't get to vendor web site,
On Tuesday 07 August 2012 01:08:24 Anurag Bhatia wrote:
router bgp 54456
bgp router-id 199.116.78.28
redistribute connected metric 1
redistribute static metric 1
neighbor 2607:1b00:10:a::1 remote-as 54456
neighbor 2607:1b00:10:a::1 next-hop-self
address-family ipv6
network
On 08/08/2012 09:37 AM, Oliver wrote:
On Tuesday 07 August 2012 01:08:24 Anurag Bhatia wrote:
router bgp 54456
bgp router-id 199.116.78.28
redistribute connected metric 1
redistribute static metric 1
neighbor 2607:1b00:10:a::1 remote-as 54456
neighbor 2607:1b00:10:a::1 next-hop-self
It seems to me that all the markets have been doing this the wrong way.
Would it now be more fair to use some kind of signed timestamp and
process all transactions in the order that they originated? Perhaps
each trade could have a signed GPS tag with the absolute time on it. It
would keep
There should be some sorts of way to authenticate a GPS timestamp. GPS
may not be able to do it today but a satellite network could in theory
cryptographically sign a time stamp so that is can only be decrypted by
the receiver at the market data center. Either that or some kind of
ground based
Also, we are only talking about a delay long enough to satisfy the
longest circuit so you could not push your timestamp very far back and
would have to get the fake one done pretty quickly in order for it to be
worthwhile. The real question is could you fake a cryptographic
timestamp fast enough
It is a tough technical problem to be sure but not insurmountable.
Think about a system in which the real time market data is also
encrypted in such a way that it can only be decrypted at a particular
point in time. Essentially it would be like each trading system
receiving an envelope that must
On Wed, Aug 08, 2012 at 08:52:51AM -0500, Naslund, Steve wrote:
It seems to me that all the markets have been doing this the wrong way.
Would it now be more fair to use some kind of signed timestamp and
process all transactions in the order that they originated? Perhaps
each trade could have
On Wed, Aug 08, 2012 at 09:08:18AM -0500, Naslund, Steve wrote:
Also, we are only talking about a delay long enough to satisfy the
longest circuit so you could not push your timestamp very far back and
would have to get the fake one done pretty quickly in order for it to be
worthwhile. The
Naslund, Steve SNaslund () medline com wrote:
It seems to me that all the markets have been doing this the wrong way.
Would it now be more fair to use some kind of signed timestamp and
process all transactions in the order that they originated? Perhaps
each trade could have a signed GPS tag
On 8/8/12 6:52 AM, Naslund, Steve wrote:
It seems to me that all the markets have been doing this the wrong way.
Would it now be more fair to use some kind of signed timestamp and
process all transactions in the order that they originated?
Given an uneven distribution of sizes it's kind of hard
Here is another thought. Many people think that the rapid computer
trading does not really add any value to the market in any case since
there is no long term investment. That point is debatable but if you
really believed that, you could end all of that by adding a randomized
delay to data
On Wed, Aug 8, 2012 at 8:08 AM, Brett Frankenberger rbf+na...@panix.com wrote:
Even if you execute the trades based on a GPS timestamp (I'm ignoring
all the logistics of preventing cheating here), it doesn't matter,
because the computer that got the information first will make the
trading
Are there not mechanisms to handle replay attacks? There is also the
minor matter of fraud and regulatory concerns. You might get away with
it a few times but not often enough to avoid a potential death penalty
of being disconnected.
Steve
-Original Message-
From: Alexandre Snarskii
No, not ever shorter under-see cables no. NEUTRINOS -shooting information
at speed of light right through the earth (not around it)
Should there be any high speed traders in here this is what you should
invest all your money in to gain advantage against your competition
First it was cold war
This is a bit like an arms race. The markets will most likely have to
level their own playing field. That is up to them. The markets may
like high frequency trading but if more and more traders become
disadvantaged they will act to level things out. They also would not
like the government to
It might be complicated. I am just saying it is probably not as
complicated as a permanent transatlantic aerial drone network or owning
your own particle accelerator. I think all the anti-replay,
anti-backdating concerns have probably been solved in the various
public/private key networks, if
Here is another thought. Many people think that the rapid computer
trading does not really add any value to the market in any case since
there is no long term investment.
It clearly doesn't. A proposal that's been kicking around for a while
is to clear all trades once a second, so everyone has
Just leaving room for disagreement on the value of HFT. It would seem to add
nothing but more volatility to the market and make small events more extreme.
There are also big risks of systems making convention wisdom decisions in
unconventional situations. Can someone pull the plug fast
Probably old news by now, but MXLogic folks are having some major
issues today and not reliably receiving inbound mail. Several of our
customers are talking with MXLogic about it.
FYI.
--
Duane Toler
deto...@gmail.com
On Wed, Aug 08, 2012 at 11:10:41AM -0500, Naslund, Steve wrote:
We are getting a bit off the NANOG subject
You think?
A
We are the same way. Phones going nuts ringing as we are an MXLogic partner.
I am slowly getting email with about a 2-3 hour delay right now. Anyone know
any more?
-Original Message-
From: Duane Toler [mailto:deto...@gmail.com]
Sent: Wednesday, August 08, 2012 10:34 AM
To:
On Wed, Aug 08, 2012 at 04:39:04PM +, Blake Pfankuch wrote:
We are the same way. Phones going nuts ringing as we are an MXLogic
partner. I am slowly getting email with about a 2-3 hour delay right
now. Anyone know any more?
-Original Message-
From: Duane Toler
Thanks for such an intelligent comment that really adds to the
discussion. For the record,
1. An article was posted talking about high speed network options.
2. I discussed why they might not be necessary
3. Various comments talked about high speed trading
4. I ended a subject that obviously
On Wed, 08 Aug 2012 09:08:27 -0500, Brett Frankenberger said:
What it's about is allowing traders to arbitrage between markets. When
product A is traded in, say, London, and product B is traded in New
York, and their prices are correlated, you can make money if your
program running in NY can
We are on .11 and .12. Our email is still a little delayed, but getting better.
-Original Message-
From: Ray Van Dolson [mailto:rvandol...@esri.com]
Sent: Wednesday, August 08, 2012 10:43 AM
To: nanog@nanog.org
Subject: Re: MXLogic outage
On Wed, Aug 08, 2012 at 04:39:04PM +, Blake
Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing
table is going nuts with Bell advertising a lot of routes they shouldn't be
On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon
zachary.mcgibbon+na...@gmail.com wrote:
Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing
table is going nuts with Bell advertising a lot of routes they shouldn't be
Bell leaked a full table. To add to the fun, it seems
On Wed, Aug 8, 2012 at 12:31 PM, Zachary McGibbon
zachary.mcgibbon+na...@gmail.com wrote:
Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing
table is going nuts with Bell advertising a lot of routes they shouldn't be
Outages mailing list is reporting that Tata is
That's what it looked like. We are connected (@ McGill University) to RISQ
and a lot of our routes started to go via RISQ-Bell instead of
RISQ-CANET/Canarie
On Wed, Aug 8, 2012 at 2:35 PM, Chris Stone axi...@gmail.com wrote:
On Wed, Aug 8, 2012 at 12:31 PM, Zachary McGibbon
On Wed, Aug 8, 2012 at 2:35 PM, Chris Stone axi...@gmail.com wrote:
Outages mailing list is reporting that Tata is having problems in Montreal
affecting 'many routers'...maybe this is related?
I am a transit customer of both TATA and Bell Canada. We saw route
churn and heavy packet loss
On 8/8/2012 2:50 PM, Jeff Wheeler wrote:
It also took over 10 minutes for my BGP withdraws to propagate from
Bell to their neighbors, including Level3. I would guess Bell
Canada's routers all have very busy CPU.
I saw the same sort of behaviour from TATA. I shut my peer with them,
yet
This is what we saw via our upstream provider, it happened twice:
[image: Inline image 1]
On Wed, Aug 8, 2012 at 2:58 PM, Mike Tancsa m...@sentex.net wrote:
On 8/8/2012 2:50 PM, Jeff Wheeler wrote:
It also took over 10 minutes for my BGP withdraws to propagate from
Bell to their
Hi,
.-- My secret spy satellite informs me that at 12-08-08 11:35 AM Darius
Jahandarie wrote:
On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon
zachary.mcgibbon+na...@gmail.com wrote:
Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing
table is going nuts with Bell
On Aug 8, 2012, at 3:50 PM, Andree Toonk wrote:
Hi,
.-- My secret spy satellite informs me that at 12-08-08 11:35 AM Darius
Jahandarie wrote:
On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon
zachary.mcgibbon+na...@gmail.com wrote:
Anyone at Bell Canada / Sympatico can tell us what's
This may be way off in the future for some of you, or others may be past
it. In support of possible work on IPv6 transition in the IETF MBONED
Working Group, I'm looking for an indication of what use cases are
realistic for operators who:
-- deliver IPTV to their customers
-- use multicast
Could this be causing issue with XO in east coast ?
-Original Message-
From: Andree Toonk [mailto:andree+na...@toonk.nl]
Sent: Wednesday, August 08, 2012 12:50 PM
To: nanog@nanog.org
Subject: Re: Bell Canada outage?
Hi,
.-- My secret spy satellite informs me that at 12-08-08 11:35 AM
Thanks for the info, looks like Bell needs to put some filtering on their
customer links!
Things seem to have calmed down now but I'm still watching my prefixes
received from my upstream provider:
while true; do snmpget -v2c -c community
router 1.3.6.1.4.1.9.9.187.1.2.4.1.1.ip of bgp peer.1.128;
On 8 August 2012 16:10, Zachary McGibbon
zachary.mcgibbon+na...@gmail.comwrote:
Thanks for the info, looks like Bell needs to put some filtering on their
customer links!
I remember when AS577 had those... ;)
--
Harald
CPU's were pegged for a customer of mine in California. tracked it
down to 2 events that went down at that time with a large message
volume.
1) Peering between GLBX and Level3 dopped somewhere, causing many
prefixes to shift away from L3 paths.
2) Some IPv6 prefixes were aggressively bouncing
Further analysis shows that there were actually 107,409 prefixes
affected of 14,391 unique origin ASn's.
Interested if your prefixes was affected?
I've uploaded a list of prefixes and ASn's that were leaked here:
http://www.bgpmon.net/bell-leak.txt
Cheers,
Andree
.-- My secret spy satellite
Ouch!! That's a lot! What do you think the outcome of this will be? What
do you think that Bell did/will do (hopefully) to fix this so it doesn't
happen again?
On Wed, Aug 8, 2012 at 4:31 PM, Andree Toonk andree+na...@toonk.nl wrote:
Further analysis shows that there were actually 107,409
On 8/8/2012 4:14 PM, Steve Dalberg wrote:
CPU's were pegged for a customer of mine in California. tracked it
down to 2 events that went down at that time with a large message
volume.
1) Peering between GLBX and Level3 dopped somewhere, causing many
prefixes to shift away from L3 paths.
They've had me blocked for a few weeks now. I've always been able to
reach it on Verizon network with iPhone, just not with Time Warner
Business Class.
I plan to take advice from kind members of group that offered it and
investigate a little more with Wireshark yet have been in middle of
client
We have been advised that TATA/6453 is back to normal, and
re-activated our BGP to them. Everything seems okay on this front.
No update from Bell Canada yet.
On Wed, Aug 8, 2012 at 4:11 PM, Harald Koch c...@pobox.com wrote:
On 8 August 2012 16:10, Zachary McGibbon
Thanks for the info, looks
Hi,
.-- My secret spy satellite informs me that at 12-08-08 11:35 AM Darius
Jahandarie wrote:
On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon
zachary.mcgibbon+na...@gmail.com wrote:
Anyone at Bell Canada / Sympatico can tell us what's going on? Our routing
table is going nuts with
telnet www.checkpoint.com 80
GET / HTTP/1.1
Host: www.checkpoint.com
...resolved some information and then lost connection according to this
trailer from the screen scrape:
!-- Column 2 --
div class=column
!--- h2a
href=https://supportcenter.checkpoint.com/supportcenter/p
On Wed, Aug 8, 2012 at 7:39 PM, Jim Ray j...@neuse.net wrote:
telnet www.checkpoint.com 80
GET / HTTP/1.1
Host: www.checkpoint.com
...resolved some information and then lost connection according to this
trailer from the screen scrape:
!-- Column 2 --
div class=column
Awe, man, don't laugh too hard. Turned out to be problem with Firefox. Safari
on iPhone and IE on PC work.
I learned something, too, and appreciate the input: tracert using ICMP is not
valid test. Not everyone has ping enabled. So, what looks like packet loss at
next hop is really ICMP turned
50 matches
Mail list logo
