Jonathan,
Inline:
Jonathan Thatcher wrote:
Hugh,
Re: cut
through market penetration: Bring this back up in 2-3 years and
we will compare notes.
If the market for cut-through is zero now, why should we expect that
the market for a new (and more complex) preemption standard will be
significant in 2.5 years. How about this: build & sell cut-through
switches now; in 3 years, if cut-through is a significant market then
we should develop a standard for preemption.
Re:
preemption backward compatibility: Of course 802.3 would create
mechanisms to ensure that a switch implementing pre-emption would plug
and play with one that didn't. You simply make the default mode equal
to the existing mode. I know that you know this. 802.3 did for Link Ag.
It did for OAM. It did for.... Come on Hugh, this isn't that hard.
Both OAM & Link Ag. use frame based protocols. Preemption will
require new (previously reserved) PCS codes. I'm sure it will work in
the vase majority of cases. If you sell tens of millions of ports per
years that equates to a very significant number of "why doesn't it
work" support calls*. If it could be proved that preemption is
worthwhile, then we should make a definition that minimizes the
complexity and interoperability problems. Personally, I think that the
net gain is too small (even in the most extreme cases) to justify the
pain.
Hugh.
* note - it's the equipment at the other end that's wrong :-)
jonathan
Jonathan,
In line:
Jonathan Thatcher wrote:
Hugh,
Well, I certainly can't get on board with the idea of
40 or 100 Gb/s being cheap or simple. At least not in the next couple
of years.
I never thought of myself as small-frame-phobic. I
always thought of myself as a lover of improved cost-performance.
You are correct that geometry matters if you want low
latency.
Regarding your comment of this being a niche of a
niche, to some of us, being a part of a 1 B$ a year and rapidly growing
niche within a 50B $ a year niche is worthy of consideration. It
doesn't especially bother me that this might be embarrassingly small
and not worthy of consideration for the largest vendors.
You (and others) would be wise not to make assumptions about what large
vendors consider worthy of attention (or not). The reason why I
classify it as a niche of a niche is that I expect most of this large
and interesting market will be satisfied by products based on standard
technologies (adapted from LAN and WAN applications). I also expect
that that there will be a significant niche demanding higher
performance (in the range discussed below) that will require more
exotic architecture. To satisfy this niche, end-station vendors will
need hardware acceleration; switch vendors may use cut-through and, as
a result, hardware will be significantly more expensive. Then there is
a niche-of-a-niche that will need faster layer 2 operation than
Ethernet can provide. I expect that such a market could use existing
supercomputer-defined interfaces or may be small enough to tolerate
custom or proprietary solutions. I do not see that the niche-of-a-niche
warrants the making of a new standard for the whole of Ethernet.
If there is any demand for preemption , then I would expect that
cut-through switching would have a significant segment of the current
market as it is a tried-and-true technology that is fully compliant
with current standards. What is the current penetration of cut-through
switches in new switch sales?
Of course a switch implementing pre-emption would
interoperate with a switch that didn't. Really Hugh, that kind of FUD
is beneath you.
Of course it won't! You would have to define some mechanism for
backward compatibility that involves discovery and negotiation before
pre-emption is used. If, for any reason, a switch were to use
preemption on an interface connected to a switch which doesn't
understand preemption then the receiving switch would see a jumbled
frames. At best this would lead to packet loss, at worst it would cause
a very high false packet acceptance rate. I would expect that such a
mix of PCS capabilities introduced into the market would generate a far
worse number of user issues than simply adding (or changing) a protocol
frame.
Hugh.
jonathan
Jonathan,
I don't know why you're so scared of smaller frames - anyone who wants
smaller latency should prefer smaller frames. If you reduce the MTU to
500 bytes (not to 48) the equation swings in favor of existing
standards:
6 x 500 x 8/10k + 0.5 = 2.9 vs 0.8 - still a 3x improvement using
preemption, but getting closer. Bear in mind that this is an extreme
worst case comparison. Averages will be almost identical because the
preempting packet can arrive at any time during the preempted frame;
the preempted frame might not be of maximum size; the link may be idle
when the preempting packet arrives; plus of course the packet in
progress may be a high priority packet also.
Of course if we start adding in more delays the difference gets yet
smaller (both delays increase similarly). e.g.
Your example allows only 15m per link, you will start to run into
geometrical problems if you want to aggregate very large numbers of
nodes with only 15m per link. If there are fewer nodes then you need to
re-architect you interconnect matrix because 6 hops should be able to
accommodate many thousands of end stations.
Your example must be assuming very aggressive cut-through switch
architecture (cut through has lost popularity in recent years, shame).
If you want to conform to the requirements of bridging then you should
wait for both the source & dest MAC address to be received before
you transmit (unless you are a repeater!). Since you are advocating
preemption, I would also assume that you must wait for the COS/TOS tag.
That extra 10 bytes will be difficult to avoid. Of course, if you
decide that the error propagation of cut-through makes the technique
unfavorable then you have a full 64 bytes of latency to wait for the
CRC of the incoming frame.
Regarding jumbo frames and complexity of end station devices, I would
expect that any device capable of filling a 10Gbps pipe will require
some hardware acceleration. For hardware implementations there really
is no significant difference between encapsulating 1500 byte frames vs
500 byte (or even smaller) frames. Hardware which performs this high
speed operation has the advantage that it is seamlessly compatible with
any other equipment that might be connected to it. On the other hand,
if a switch started using a preemption mechanism when connected to any
existing hardware then it could be anybody's guess what would result.
My assertion is that a small reduction in MTU for the local network
will yield results which are close enough to your extreme examples to
make the applicable space where a new standard is demanded very small
indeed. As I said, it's a niche of a niche.
Better to spend our effort on cheap and simple 40Gig (or even 100Gig)
and make this whole argument moot (yes, at 100G the max length frame
can be stored in 25m of wire).
Hugh.
|