Finally, some visible progress

mogul (Jeffrey Mogul) Fri, 12 January 1990 23:35 UTC

Received: by acetes.pa.dec.com (5.54.5/4.7.34) id AA26646; Fri, 12 Jan 90 15:35:25 PST
From: mogul (Jeffrey Mogul)
Message-Id: <9001122335.AA26646@acetes.pa.dec.com>
Date: 12 Jan 1990 1535-PST (Friday)
To: mtudwg
Cc:
Subject: Finally, some visible progress

Most of you may have wondered what has happened to this working group.
Well, as you may remember, Keith McCloghrie and Rich Fox volunteered at
the meeting (exactly one month ago today) to draft an RFC describing
the protocol we arrived at during the meeting.

Keith, Rich, and I have exchanged numerous messages and several drafts
of the RFC, and (because the February IETF is less than a month away)
it is now time to circulate it among the members of the group.

Some of you might notice on your own that we've made some changes from
the consensus proposal that emerged from the meeting.  Most importantly,
we have eliminated any transport-level involvement in the discovery
protocol itself.  I don't think any of you actually wanted transport-level
involvement, although some argued that it appeared to be necessary.
Keith and Rich have worked out a simple, although fairly subtle, mechanism
that allows all the work to be done at the IP level and yet doesn't pollute
the net with lots of ICMPs if someone happens to run NFS at the wrong time.

The very astute reader will realize that this is no longer really Steve
Deering's "Report Fragmentation" scheme at all, but something that we
are calling "Unexpected Fragment Report" which tracks changes in the
apparent MTU rather than simply the occurrence of fragmentation.  For
the less-astute reader: well, now you know anyway.

We have also simplified the format of the IP Path MTU (PMTU) Query
option; this was driven by the scarcity of space in the IP header
option area.  The "Valid" flag is now implicitly encoded in the
next-hop address field, saving one bit.  The "Fragmentation Report
Allocation" (original Keith's send-N reports mechanism) has been
changed, from something sent in the option by the sender, to an
architected constant; this is because we didn't expect the senders to
actually excercise any discretion in the value, and we saved another
few bits in the IP option (meaning at least one byte!).

My hope is that during the next 3 weeks we will be able to arrive at a
consensus that the basic scheme is either sound or unsound, and argue
about some of the details.  At the February IETF meeting (which Keith,
Rich, and I plan to attend) we have a half-afternoon session scheduled
(Wednesday, Feb. 7), and I hope that at that meeting we can lay to rest
any remaining doubts.  In other words, allowing some time for final
draft preparation, we should have an RFC out in early March.

The RFC itself follows in another message.

-Jeff