On 9/20/23 19:15, George Michaelson wrote:
It's fine to pile up on the other SDO but I think this is a false
argument.
To clarify, I'm not trying to "pile up" on ISO or any other SDO. I'm
just saying that a bit of diversity in approaches overall is a feature.
The Internet benefits tremendously from the work of several other SDOs,
especially in hardware layers, and I certainly don't think that IETF is
(or ever would have been) well-positioned to do all of that work itself.
X.25 carried forward in the ITU bis/ter process wouldn't
look like it did "then" it would look much more like something which
worked adequately in gigabit networks,
I doubt it. To work well at such high speeds would have required a
drastically different approach than ever contemplated for X.25, and it
would still have had to compete with other technologies specifically
designed for high-speed fiber, in different eras and subject to
different constraints for that reason.
I'm more concerned that we were going to variable length addresses in
CLNP. John Scudder's presentation to IEPG a while back stressed that
variability in the front part of a packet was anathema to fast path
processing in the FPGA, you want constant shape headers to process
them quickly. I think we'd have had to settle on fixed length
addresses pretty quickly.
At least at the time (early 1990s) I thought you could probably design a
packet format that would have accommodated variable length addresses
while still permitting fast path processing in hardware. Nothing says
the entire address has to be contiguous in the header, for example.
And I believed that the IP header didn't have to be intact on-the-wire,
it could take on a different form on any particular link layer, just as
IP header compression effectively does that.
But I didn't think I could sell that idea back then, or that it would be
helpful to try, even though I saw an advantage to variable length
addresses. There were already too many competing ideas for IPng, and
the selection process was already taking too long. And I was happy with
IPv6 when the smoke cleared it finally emerged. I just wish it had
emerged, say, a year earlier.
Speaking of sessions, In reality, I feel QUIC is closer to the ISO
reference session layer than a transport, and a remarkably good fit
for X.400 on top. I don't have a problem with X.400, there are days I
think that X.25 aside, it might have been better for us all if we'd
adopted it rather than sticking to SMTP.
X.400 has a lot of problems that most of us never fully experienced
because it never saw widespread use. The address format was a joke, an
anachronism from the days when it was assumed that PTTs would naturally
administer email and networks. The message format suffers from what I
call ASN.1 disease - the tendency to specify protocols too precisely and
too inflexibly. RFC822 style headers are better in most respects because
they allow for many kinds of extensibility not anticipated by their
original design and without breaking backward compatibility or needing
timely widespread upgrades. (Perhaps counterintuitively,
over-specification of protocols often degrades interoperability rather
than aiding it.) X.400's assumptions about routing (though perhaps not
embedded in the protocol itself - I threw away my X.400 specifications
decades ago) simply didn't scale (either administratively or
technically) and quite often resulted in network congestion. About the
only thing I recall liking about it was that it almost had a clean
separation between envelope and payload, but didn't even get that quite
right.
And if you want to know why a certain large vendor's email product is a
huge resource hog, it might be because internally it was based on X.400.
Keith
