Re: Comments on PMTU-Draft-RFC

Steve Deering <deering@pescadero.stanford.edu> Tue, 30 January 1990 02:32 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA09668; Mon, 29 Jan 90 18:32:05 PST
Received: by decwrl.dec.com; id AA19838; Mon, 29 Jan 90 18:32:02 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA18281; Mon, 29 Jan 90 18:31:58 PDT
Date: 29 Jan 1990 18:18-PST
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: Comments on PMTU-Draft-RFC
To: mtudwg
Message-Id: <90/01/29 1818.266@pescadero.stanford.edu>

Here's my two cents worth:

page 4, last item/paragraph: the first two sentences could be clarified to
indicate that the problem is deciding which *initial* fragments (i.e.,
fragments with offset 0) should elicit fragmentation reports.  Nobody has
ever suggested sending reports in response to non-initial fragments.  The
way it is written makes the problem sound much worse than it is.

page 5, first item/paragraph: I had to read this over several times to
understand what you were talking about.  In my RF-bit scheme, there is no
need for receiver state to indicate which applications understand
fragmentation reports -- the bit in the IP header tells the receiver.  The
problem you identify arises only with the IP option approach to report-
fragmentation, and only because sending an option on every datagram is too
expensive.  Could this paragraph be made clearer and more accurate?

(By the way, it was pointed out to me that the "RF-bit" is *not* the only
unused bit in the IP header -- there are two more unused bits in the
type-of-service byte.  I think that weakens the case of those who oppose
the use of the RF-bit for fragmentation detection; if there should arise
other needs for new IP header bits, such as DEC-bit-style congestion control,
they could be satisfied with the spare TOS bits.  But I digress.)

page 6, third paragraph: I agree with Pradeep, concerning the confusion over
whether or not the next-hop field contains zero.  Seems to me there is *no*
need ever to set it to zero -- the decision can always be: "is this my address
or not".  As it is, you've introduced three states (my address, zero, other),
when only two are needed (my address, other), making it harder to understand
the protocol.  Or have I missed some subtle requirement for three states?

page 7 and 22: change all occurrences of 576 to MIN(576,first-hop-MTU)
That is, you don't use 576 as the default PMTU if your first-hop MTU is
less than 576.

page 9, last item/paragraph (also, page 19, first paragraph): you fail to
mention how the transport/application layer detects increases of PMTU;
presumably it requires periodic calls to GET_MAXSIZES.  (Or, you could argue
that the transport/application layer need not detect increases.  In any case,
it should be discussed.)

page 14, definition of Src_PMTU: change "this cache entry's host" to "this
cache entry's host and type-of-servce".

page 16, second paragraph: change "one entry per host" to "one entry per host
and type-of-service", or something like that.  (This gets even worse when
routes may be influenced by security options, policy-based routing, etc, which
does not bode well for the notion of caching per-route info at a destination.
Do you want to mention this somewhere?)

page 16, list of destination cache fields: should include an "Age" field for
timing out old cache entries?

page 19, first paragraph, last (bracketed) sentence: the GET_MAXSIZES
operation does provide the first-hop MTU, if you pass it the address of a
neighbor.  Why do need/want a more general operation to query the MTU of a
connected network, given the way your protocol works?  (I know that *my*
proposal would require the new operation, because it puts more burden on the
transport/application layer, but it's not clear why your protocol needs it.)

page 19, second paragraph: the long, last sentence beginning "In
particular,..." is very confusing.  Can you fix this somehow?

page 20, section 8.5: do you want to mention proxy-ARP situations?  That's
a case where PMTU discovery would be useful, but the sender thinks it is
sending to a neighbor.  Of course, in that case, the next-hop field doesn't
work too well.  Is proxy ARP being actively discouraged yet?

do you want to mention anywhere that the PMTU derived from a fragment 0 may
be as much as 7 bytes less than the true PMTU, due to fragmentation on 8-byte
boundaries?

grammatical nits:

	page 13, last paragraph: remove comma after "paths to other hosts".

	page 17, third paragraph, first sentence: change "for sending Host"
	to "for the sending host".

	the word "which" should be changed to "that" in many places.

concluding remark: it's too bad the protocol ended up so complicated.

Steve