[ih] Impact of history on today's technology [was: why did CC happen at all?]

[Paul Vixie]

On 9/5/2014 1:20 PM, Brian E Carpenter wrote:
> On 06/09/2014 01:48, Dave Crocker wrote:
>
>> Perhaps you have in mind something like the technological issue of
>> typewriter keys getting stuck against each other if the typist went to
>> fast, thereby motivating the qwerty layout?
> It could be almost anything that has enduring effects. Another one is that
> whatever design compromise led to 1500 bytes for Ethernet in 1983 affects
> every discussion today about IPv6 PMTUD and fragmentation.

the way david boggs explained "1500" to me, it sounded like a design
balancer moreso than a compromise.

> However much the technical constraint is obsolete, we can't get rid of it.

the "1500" problem is still with us because each new generation of
ethernet begins by being bridged or repeated from the prior generation
of ethernet. i remember once having the idea in mind that we'd use 1500
for our Fast-E (100MBit) networks until the last 10MBit device was
upgraded. sadly, that was easier to imagine than to plan for.

the same thing happened with "512" as a DNS payload maximum when carried
in UDP. the original idea was that the smallest reassembly buffer that
an IP4 receiver was allowed to have and still interoperate was 568
octets, which with IP and UDP headers and extensions, left 512 octets.
so when we moved from IP4 to IP6 and got a new and higher guaranteed
minimum maximum of 1280, we should ideally have been able to relax that
constraint. however, a lot of IP4->IP6 and IP6->IP4 transition
technologies came about, including ALG (UDP proxies), and so we had to
send no more than 512 octets of DNS payload even when speaking to what
we thought was an IP6 destination. and let me assure everybody, EDNS
(RFC 2671) as a signalling method to increase this, has taken 15 years
to reach less than 50% of the installed base.

so, what's a protocol designer to do? granted most new protocols are
carried on TCP/80 and there's rarely a length constraint, the question
remains: how to future-proof a protocol without excessively burdening
the early adopters? (DNS could not have taken off had it been a TCP-only
protocol, for example.)

vixie