On Sat, 6 Nov 2010, George Bonser wrote:
And by that I mean using 1500 MTU is what degrades the performance, not
the ethernet physical transport. Using MTU 9000 would give you better
performance than SONET. That is why Internet2 pushes so hard for people
to use the largest possible MTU and t
I'm seeing DNS lookup failures for us.af.mil, usmc.mil, us.army.mil, and
navy.mil. Possibly more .mil are affected. This is getting way too
frequent. Anybody got a good out-of-band (not .mil) contact for reporting
this?
Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: t...@lava.net
I won't speak to the wrong solution for the wrong market but as far as
large ACLs, I would agree with Tony.
I've seen hundreds of different ASA configurations for a variety of
customers in a variety of markets and generally once you start
reaching the limits of the box you start losing sight of wh
> > * gbon...@seven.com (George Bonser) [Sun 07 Nov 2010, 04:27 CET]:
> > >It just seems a shame that two servers with FDDI interfaces using
> > SONET
> >
> > Earth to George Bonser: IT IS NOT 1998 ANYMORE.
>
> Exactly my point. Why should we adopt newer technology while using
> configuration p
> -Original Message-
> From: Niels Bakker [mailto:niels=na...@bakker.net]
> Sent: Saturday, November 06, 2010 8:32 PM
> To: nanog@nanog.org
> Subject: Re: RINA - scott whaps at the nanog hornets nest :-)
>
> * gbon...@seven.com (George Bonser) [Sun 07 Nov 2010, 04:27 CET]:
> >It just see
On 11/6/2010 10:31 PM, Niels Bakker wrote:
* gbon...@seven.com (George Bonser) [Sun 07 Nov 2010, 04:27 CET]:
It just seems a shame that two servers with FDDI interfaces using SONET
Earth to George Bonser: IT IS NOT 1998 ANYMORE.
We don't fly sr71s or use bigger MTU interfaces. Get with the
* gbon...@seven.com (George Bonser) [Sun 07 Nov 2010, 04:27 CET]:
It just seems a shame that two servers with FDDI interfaces using SONET
Earth to George Bonser: IT IS NOT 1998 ANYMORE.
-- Niels.
> I'd like to order a dozen of those 40ms RTT LA to NYC wavelengths,
> please.
>
> If you could just arrange a suitable demonstration of packet-level
> delivery
> time of 40ms from Los Angeles to New York and back, I'm sure there
> would
> be a *long* line of people behind me, checks in hand.^
>
> I prefer much less packet loss in a majority of my transmissions,
which
> in turn brings those numbers closer together.
>
>
> Jack
True, though t the idea that it greatly reduces packets in flight for a
given amount of data gives a lot of benefit, particularly over high
latency connections.
On Sat, Nov 6, 2010 at 5:21 PM, George Bonser wrote:
...
> (quote)
> Let's take an example: New York to Los Angeles. Round Trip Time (rtt) is
> about 40 msec, and let's say packet loss is 0.1% (0.001). With an MTU of
> 1500 bytes (MSS of 1460), TCP throughput will have an upper bound of
> about 6.
Hi all,
do you know if I will be able to use two different vendors to execute
these tests ? For example, let's say that I have one JDSU unit in the
side A and a EXFO unit in the side B. Will these tests work ?
If not, is there a way to execute these tests having two different vendors ?
Thanks
./
On 11/6/2010 7:21 PM, George Bonser wrote:
(quote)
Let's take an example: New York to Los Angeles. Round Trip Time (rtt) is
about 40 msec, and let's say packet loss is 0.1% (0.001). With an MTU of
1500 bytes (MSS of 1460), TCP throughput will have an upper bound of
about 6.5 Mbps! And no, that i
On Sat, 06 Nov 2010 11:45:01 -0500
Jack Bates wrote:
> On 11/5/2010 5:32 PM, Scott Weeks wrote:
> >
> > It's really quiet in here. So, for some Friday fun let me whap at the
> > hornets nest and see what happens...>;-)
> >
> >
> > http://www.ionary.com/PSOC-MovingBeyondTCP.pdf
> >
>
> SCTP is
On Sat, Nov 06, 2010, Andy Davidson wrote:
> Not withstanding Mikael's comments that it shouldn't be lossy, at times when
> you want to simulate lossy (and jittery, and shaped, and ) conditions,
> the best way I have found to do this is FreeBSD's dummynet :
>
> http://www.freebsd.org/cgi/ma
> So if you consider >5x performance boost to be "minimal" yeah, I
guess.
> Or being able to operate at todays transfer rates in the face of 36x
> more packet loss to be "minimal" improvement, I suppose.
And those improvements in performance get larger the longer the latency
of the connection. F
>
> On the contrary. You're proposing to fuck around with the one place
> on the whole Internet that has pretty clear and well adhered-to rules
> and expectations about MTU size supported by participants, and
> basically re-live the problems from MAE-East and other shared
> Ethernet/FDDI platform
* gbon...@seven.com (George Bonser) [Sun 07 Nov 2010, 00:30 CET]:
Re: large MTU
One place where this has the potential to greatly improve
performance is in transfers of large amounts of data such as vendors
supporting the downloading of movies, cloud storage vendors, and
movement of other lar
On Nov 6, 2010, at 10:38 AM, Mark Smith wrote:
> On Fri, 5 Nov 2010 21:40:30 -0400
> Marshall Eubanks wrote:
>
>>
>> On Nov 5, 2010, at 7:26 PM, Mark Smith wrote:
>>
>>> On Fri, 5 Nov 2010 15:32:30 -0700
>>> "Scott Weeks" wrote:
>>>
It's really quiet in here. So, for some
On Sat, Nov 06, 2010 at 03:49:19PM -0700, George Bonser wrote:
>
> When the TCP/IP connection is opened between the routers for a routing
> session, they should each send the other an MSS value that says how
> large a packet they can accept. You already have that information
> available. TCP p
Re: large MTU
One place where this has the potential to greatly improve performance is
in transfers of large amounts of data such as vendors supporting the
downloading of movies, cloud storage vendors, and movement of other
large content and streaming. The *first* step in being able to realize
tho
Or Linux Netem
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
Suresh
On Sat, Nov 6, 2010 at 6:50 AM, Andy Davidson wrote:
>
> On 6 Nov 2010, at 05:53, Saqib Ilyas wrote:
>
>> A friend of mine is doing some testing where he wishes to emulate a
>> cellular-like interfaces
>
> and that verified that the problem was an MTU black hole. A little
> reading revealed why Solaris wasn't having the problem but Linux did.
> Setting the Linux ip_no_pmtu_disc sysctl to 1 resulted in the Linux
> behavior matching the Solaris behavior.
Oops, meant tcp_mtu_probing
>
> The only thing this adds is trial-and-error probing mechanism per
flow,
> to try and recover from the infinite blackholing that would occur if
> your ICMP is blocked in classic PMTUD. If this actually happened in
any
> scale, it would create a performance and overhead penalty that is far
> wor
On 11/6/2010 3:14 PM, George Bonser wrote:
It ships with Microsoft Windows as "Blackhole
Router Detection" and is on by default since Windows 2003 SP2.
The first item returned on a blekko search is the following article
which indicates that it is on by default in Windows
2008/Vista/2003/XP/20
On Sat, Nov 06, 2010 at 02:21:51PM -0700, George Bonser wrote:
>
> That is not a new problem. That is also true to today with "last
> mile" links (e.g. dialup) that support <1500 byte MTU. What is
> different today is RFC 4821 PMTU discovery which deals with the "black
> holes".
>
> RFC 4821
> >
> While it reads well, what implementations are actually in use? As with
> most protocols, it is useless if it doesn't have a high penetration.
>
> Jack
Solaris 10, in use and on by default. Available on Windows for a very
long time as "blackhole router detection" was off by default original
>
> As long as the implementations are few and far between:
>
> https://www.psc.edu/~mathis/MTU/
> http://www.ietf.org/mail-archive/web/rrg/current/msg05816.html
>
> the traditional ICMP-based PMTUD is what most of use face today.
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
On 06/11/10 15:56 -0500, Jack Bates wrote:
On 11/6/2010 3:36 PM, Richard A Steenbergen wrote:
#2. The major vendors can't even agree on how they represent MTU sizes,
so entering the same # into routers from two different vendors can
easily result in incompatible MTUs. For example, on Juniper wh
On 11/6/2010 4:52 PM, George Bonser wrote:
That is also somewhat mitigated in that it operates in two modes. The
first mode is what I would call "passive" mode and only comes into play
once a black hole is detected. It does not change the operation of TCP
until a packet disappears. The second
> > > RFC 4821 PMTUD is that "negotiation" that is "lacking". It is there.
> > > It is deployed. It actually works. No more relying on someone sending
> > > the ICMP packets through in order for PMTUD to work!
> >
> > For some value of "works". There are way too many places filtering
> > ICMP f
>
> He was referring to the updated RFC 4821.
>
> " In the absence of ICMP messages, the proper MTU is determined by
> starting
> with small packets and probing with successively larger packets.
> The
> bulk of the algorithm is implemented above IP, in the transport
> layer
> (e.g., T
>
> While I think 9k for exchange points is an excellent target, I'll
> reiterate
> that there's a *lot* of SONET interfaces out there that won't be going
> away any time soon, so practically speaking, you won't really get more
> than 4400 end-to-end, even if you set your hosts to 9k as well.
Ag
On 11/6/2010 4:40 PM, sth...@nethelp.no wrote:
For some value of "works". There are way too many places filtering
ICMP for PMTUD to work consistently. PMTUD is *not* the solution,
unfortunately.
He was referring to the updated RFC 4821.
" In the absence of ICMP messages, the proper MTU is d
> -Original Message-
> From: sth...@nethelp.no [mailto:sth...@nethelp.no]
> Sent: Saturday, November 06, 2010 2:40 PM
> To: George Bonser
> Cc: r...@e-gerbil.net; nanog@nanog.org
> Subject: Re: RINA - scott whaps at the nanog hornets nest :-)
>
> > RFC 4821 PMTUD is that "negotiation" that
> RFC 4821 PMTUD is that "negotiation" that is "lacking". It is there.
> It is deployed. It actually works. No more relying on someone sending
> the ICMP packets through in order for PMTUD to work!
For some value of "works". There are way too many places filtering
ICMP for PMTUD to work consist
> Completely agree with you on that point. I'd love to see Equinix, AMSIX,
> LINX,
> DECIX, and the rest of the large exchange points put out statements indicating
> their ability to transparently support jumbo frames through their
> fabrics, or at
> least indicate a roadmap and a timeline to whe
On Sat, Nov 6, 2010 at 2:21 PM, George Bonser wrote:
>
...
> As for the configuration differences between units, how does that change
> from the way things are now? A person configuring a Juniper for 1500
> byte packets already must know the difference as that quirk of including
> the headers is
Le samedi 06 novembre 2010 à 13:29 -0700, Matthew Petach a écrit :
> On Sat, Nov 6, 2010 at 1:22 PM, George Bonser wrote:
> >> >
> >> > Last week I asked the operator of fairly major public peering points
> >> if they supported anything larger than 1500 MTU. The answer was "no".
> >> >
> >>
> >>
> It's perfectly safe to have the L2 networks in the middle support the
> largest MTU values possible (other than maybe triggering an obscure
> Force10 bug or something :P), so they could roll that out today and
you
> probably wouldn't notice. The real issue is with the L3 networks on
> either end
Le samedi 06 novembre 2010 à 13:01 -0700, Matthew Petach a écrit :
> On Sat, Nov 6, 2010 at 12:32 PM, George Bonser wrote:
> >> I doubt that 1500 is (still) widely used in our Internet... Might be,
> >> though, that most of us don't go all the way to 9k.
> >>
> >> mh
> >
> > Last week I asked the
On 11/6/2010 2:15 PM, George Bonser wrote:
I believe SCTP will become more widely used in the mobile device world. You can have
several different streams so you can still get an IM, for example, while you are
streaming a movie. Eliminating the "head of line" blockage on thin connections
is r
On 11/6/2010 3:36 PM, Richard A Steenbergen wrote:
#2. The major vendors can't even agree on how they represent MTU sizes,
so entering the same # into routers from two different vendors can
easily result in incompatible MTUs. For example, on Juniper when you
type "mtu 9192", this is INCLUSIVE of
>
> Completely agree with you on that point. I'd love to see Equinix,
> AMSIX, LINX,
> DECIX, and the rest of the large exchange points put out statements
> indicating
> their ability to transparently support jumbo frames through their
> fabrics, or at
> least indicate a roadmap and a timeline to
On Sat, Nov 06, 2010 at 12:32:55PM -0700, George Bonser wrote:
> > I doubt that 1500 is (still) widely used in our Internet... Might be,
> > though, that most of us don't go all the way to 9k.
>
> Last week I asked the operator of fairly major public peering points
> if they supported anything la
On Sat, Nov 6, 2010 at 1:22 PM, George Bonser wrote:
>> >
>> > Last week I asked the operator of fairly major public peering points
>> if they supported anything larger than 1500 MTU. The answer was "no".
>> >
>>
>> There's still a metric buttload of SONET interfaces in the core that
>> won't go
> >
> > Last week I asked the operator of fairly major public peering points
> if they supported anything larger than 1500 MTU. The answer was "no".
> >
>
> There's still a metric buttload of SONET interfaces in the core that
> won't go above 4470.
>
> So, you might conceivably get 4k MTU at som
> 1500 was fine for 10G
I meant, of course, 10M ethernet.
>
> There's still a metric buttload of SONET interfaces in the core that
> won't go above 4470.
>
> So, you might conceivably get 4k MTU at some point in the future, but
> it's really, *really* unlikely you'll get to 9k MTU any time in the
> next
> decade.
>
> Matt
Agreed. But even 4470 is bet
On Sat, Nov 6, 2010 at 12:32 PM, George Bonser wrote:
>> I doubt that 1500 is (still) widely used in our Internet... Might be,
>> though, that most of us don't go all the way to 9k.
>>
>> mh
>
> Last week I asked the operator of fairly major public peering points if they
> supported anything larg
> I doubt that 1500 is (still) widely used in our Internet... Might be,
> though, that most of us don't go all the way to 9k.
>
> mh
Last week I asked the operator of fairly major public peering points if they
supported anything larger than 1500 MTU. The answer was "no".
Le samedi 06 novembre 2010 à 12:15 -0700, George Bonser a écrit :
> > Sent: Saturday, November 06, 2010 9:45 AM
> > To: nanog@nanog.org
> > Subject: Re: RINA - scott whaps at the nanog hornets nest :-)
> >
> > On 11/5/2010 5:32 PM, Scott Weeks wrote:
> > >
> > > It's really quiet in here. So, for
Thank you
On Sat, Nov 6, 2010 at 3:12 AM, Mehmet Akcin wrote:
>
> On Nov 5, 2010, at 3:19 PM, Santino Codispoti wrote:
>
>> Does anyone have an up to date list of the carriers that are within
>> the NAP of the Capital Region?
>>
>
> Abovenet
> At&t
> Level3
> Verizon
> TATA
> Cogent (I am being t
> Sent: Saturday, November 06, 2010 9:45 AM
> To: nanog@nanog.org
> Subject: Re: RINA - scott whaps at the nanog hornets nest :-)
>
> On 11/5/2010 5:32 PM, Scott Weeks wrote:
> >
> > It's really quiet in here. So, for some Friday fun let me whap at
> the hornets nest and see what happens...>;-)
>
On 11/5/2010 5:32 PM, Scott Weeks wrote:
It's really quiet in here. So, for some Friday fun let me whap at the hornets
nest and see what happens...>;-)
http://www.ionary.com/PSOC-MovingBeyondTCP.pdf
SCTP is a great protocol. It has already been implemented in a number of
stacks. With the
On Fri, 5 Nov 2010 21:40:30 -0400
Marshall Eubanks wrote:
>
> On Nov 5, 2010, at 7:26 PM, Mark Smith wrote:
>
> > On Fri, 5 Nov 2010 15:32:30 -0700
> > "Scott Weeks" wrote:
> >
> >>
> >>
> >> It's really quiet in here. So, for some Friday fun let me whap at the
> >> hornets nest and see w
- Original Message -
From: "gordon b slater"
To: "Tony Varriale"
Cc:
Sent: Saturday, November 06, 2010 4:38 AM
Subject: Re: BGP support on ASA5585-X
On Fri, 2010-11-05 at 21:50 -0500, Tony Varriale wrote:
said:
>They could make it out of the box but this is why Dylan made his
On 6 Nov 2010, at 05:53, Saqib Ilyas wrote:
> A friend of mine is doing some testing where he wishes to emulate a
> cellular-like interfaces with random drops and all, out of an ethernet
> interface. Since we have plenty of network and system ops on the list, I
> thought we might have luck postin
On 11/1/10 9:42 PM, Nathan Eisenberg wrote:
>> My guess is that the millions of residential users will be less and
>> less enthused with (pure) PA each time they change service providers...
Hi, almost everytime I open my laptop it gets a different ip address,
sometimes I'm home and it gets that sa
On Fri, 2010-11-05 at 21:50 -0500, Tony Varriale wrote:
> said:
> >They could make it out of the box but this is why Dylan made his statement.
>
> His statement is far fetched at best. Unless of course he's speaking of 100
> million line ACLs.
Can I just ask out of technical curiosity:
Q: Wh
On Nov 5, 2010, at 3:19 PM, Santino Codispoti wrote:
> Does anyone have an up to date list of the carriers that are within
> the NAP of the Capital Region?
>
Abovenet
At&t
Level3
Verizon
TATA
Cogent (I am being told is joining or has just joined)..
Terremark's transit network
I actually have a
Subject: RINA - scott whaps at the nanog hornets nest :-) Date: Fri, Nov 05,
2010 at 03:32:30PM -0700 Quoting Scott Weeks (sur...@mauigateway.com):
>
>
> It's really quiet in here. So, for some Friday fun let me whap at the
> hornets nest and see what happens... >;-)
>
>
> http://www.ionary
61 matches
Mail list logo
