Re: Ethernet-FDDI woes

jnc@PTT.LCS.MIT.EDU (Noel Chiappa) Mon, 04 December 1989 03:07 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA01687; Sun, 3 Dec 89 19:07:08 PST
Received: by decwrl.dec.com; id AA11706; Sun, 3 Dec 89 19:07:04 -0800
Received: by PTT.LCS.MIT.EDU id AA04170; Sun, 3 Dec 89 22:01:41 EST
Date: Sun, 03 Dec 1989 22:01:41 -0500
From: jnc@PTT.LCS.MIT.EDU
Message-Id: <8912040301.AA04170@PTT.LCS.MIT.EDU>
To: craig@nnsc.nsf.net
Subject: Re: Ethernet-FDDI woes
Cc: mogul, mtudwg%decwrl.dec.com.jnc@lcs.mit.edu

	Right, there is this Ether-FDDI thing. It turns out there is a new
'Multi-Media Bridges WG' which is going to discuss this (and may recommend
against it; it's up to them), but let me just mention a problem with that
approach.
	The proposal to used 'mixed' MTU's on a single network would require
hosts to keep MTU's on a per-destination basis for destinations on the local
interface, not per interface as per the Host RFC. This is not bad per se, but
the IETF has been requested to 'limit the rate of change', so redoing the
Host RFC anytime soon is out. That being the case, you can imagine a number
of failure modes involving jumbo-grams and 'old' hosts that still follow the
Host RFC.
	I assume all the mechanisms this group are exploring will be able to
fit in in an upwardly compatible way, right?  I mean, we can write the RFC
now, but we can't respin the Host RFC right away to refer to it. In any case,
just because we write in the RFC doesn't mean that overnight all 150K machines
come up to spec!

	Noel

PS: I hope nobody's too bummed at me for the cold water on the fragmentation
bit. It's just that we do only have bit, and Congestion is really a big
problem...