RE: MAE-EAST Moving? from Tysons corner to reston VA.

["Roeland Meyer (E-mail)" <rmeyer () mhsc com>]

> Richard A. Steenbergen: Saturday, June 17, 2000 7:55 AM
>
> On Sat, 17 Jun 2000, RJ Atkinson wrote:
>
> > Sounds like a filter on which product one buys. :-)
>
> Based on those who don't support a non-standard extension? At
> any rate,
> people will buy them, and problems will ensue. :P

Currently, there are places in internal sites that are doing
exactly this. What happens is, in the interests of invoice
standardization, the same filter is being applied to the
externally visible equipment. My personal nightmare is some tech
using the wrong NIC in the wrong machine and the architecture (my
responsibility area) is erroneously shown to fail. It is far
safer to spec the same equipment/capability homogenously and
eliminate that failure-mode <grin>.

> I see its getting better though, there is more support then
> there used to
> be the last time I looked.

Uneven distribution is always an issue during technology
roll-out/adoption. I expect it to take years, with some
extentions being orphaned, and it could even cause some market
re-alignments and new vendors to pop up... normal stuff, prior to
feature commoditization.

> > > The point is that unless everyone makes these changes, any
> attempt to run
> > > a higher MTU along a non-supporting path without a reliable
PMTU-D
> > > mechanism will result in bloody horror.
> >
> > For content replication, as differentiated from content
> distribution,
> > the larger MTU should be safe.  A larger than 1518 MTU won't
be
> > safe for content distribution anytime soon because the Cable
Modem
> > standards specify a 1518 MTU and cable modems are a leading
way
> > to provide high performance networking to homes.

Does anyone know if this same restriction applies to any form of
DSL? If so, then this capability will rapidly become a data
center internal-only usage. This will also restrict its usage on
the co-lo trunks. Otherwise, we need to point at the cable-modem
specs and get that changed. As alluded to previously, there are
some who take the MTU=1500 issue with religious zeal. They will
resist all rational argument in this. MTU values should remain a
configuration parameter and should not be spec'd in the
protocol... ever!


> Based off 4.0-STABLE, using some work I'm doing on the FreeBSD
TCP/IP
> stack (mainly cleaner code and a few trivial optimizations at
> this point,
> nothing earth shattering), some additional optimizations and
shortcuts
> through the stack based on IP Flow which I'm writing, using
> back to back
> NetGear GA620s, 512k send/recvspace buffers and a 1MB socket
> buffer, and a
> really quick in-kernel ack & discard in the receiving end.

<g> You will release open-source so the Linux community can use
<please>?

> The last time I tried it with standard userland transfers was
> on back to
> back p3 500s which pulled about 450Mbps between a GA620 and
> an Intel GE.

This is much better than what I'm seeing (MTU=1500). With
MTU=4096+40 I get closer. I've not tried higher MTU values
because not all of my equipment supports it. Have you done any
analysis of MTU=<value> vs. thoughput? If so, at what increment?

> > > It would
> > > certainly help to be doing less packets/rateoftime though,
> as this is a
> > > (the?) major bottleneck.
> >
> > Packet processing overhead and memory manipulation are
generally
> > the bottlenecks in hosts.  There is substantial literature to
> > this effect.

> Isn't that the truth. I think of a lot of it is poorly
optimized and
> well-planned code though.

In defense of the programmer, code dealing with a fixed MTU value
can be much more efficient than code that has to discover MTU
value at run-time. I suspect that this may also be the case for
cable-modems. It would have a direct effect on CPU cost and
therefore COGm. At a scale of 10M units, $0.001 COGm can add up
to a lot of money. However, this is a transitive benefit, as
CPU/RAM gets cheaper and faster. Ascend found this out with the
Pipeline 25 (a lot of which they've had to replace with Pipeline
75's, under warranty, resulting in reduced profitablility,
overall [to Ascend's credit, they actually did it, where
warranted, at no additional consumer cost]). I don't intend this
to be a defense for a fixed MTU value, I am only postulating a
probable cause for its appearance in the cable-modem spec (that
they are not completely irrational<g>).