Some additional comments:
Section 3.4
I am not comfortable with much of the discussion in this section.
As noted, much of the discussion is academic because in fact, bit errors
do not happen in isolation. Also, while it is possible to implement
stronger frame
checking mechanisms, doing so at line rate (e.g. 10+ Gbps) is non-trivial.
If this material is intended to remain within the document, it needs to be
reviewed by IEEE 802.3 folks such as Pat Thaler.
Section 4.1
With the advent of Energy Efficient Ethernet, it will be possible for link
rate
to be adjusted in mid-conversation. Therefore the having the allowed MTU
vary with link speed will mean that the MTU could conceivably change in
the middle of a conversation between two hosts.
Section 4.3
Having a layer 2 switch advertise its maximum MTU will not necessary provide
a host with useful information, since depending on the operation of (R)STP,
the switch may or may not be in the path. Also, with Energy Efficient
Ethernet, one or more links along the path may adjust their speed; if
the MTU were to vary, this would cause changes to the path MTU that
the host would not be to predict, even knowing the link speed-MTU
relationship of its edge switch.
From: John Heffner <[EMAIL PROTECTED]>
To: Iljitsch van Beijnum <[EMAIL PROTECTED]>
CC: [email protected]
Subject: Re: [Int-area] draft-van-beijnum-multi-mtu-00
Date: Sun, 26 Aug 2007 00:44:28 -0400
Comments on draft-van-beijnum-multi-mtu-00
First, I'd like to say that I agree with the goal of being able to run
mixed-MTU subnets. I'm not yet convinced this draft constitutes a full and
practical solution to the problem.
I have some specific comments below divided by section. A few general ones
first:
One thing that might make the draft easier to read would be some discussion
of how the pieces described in Section 4 fit together to form a solution to
the problem presented.
I think the draft is a bit too focused on Ethernet. For example,
specifying 1500 byte minimum MTUs. A standard in this area should apply
equally to all link types.
The discussion in Section 3 is pretty good, but it might be a bit long and
detailed for this doc.
4.1:
It's not clear what exactly the Allowed MTU and Off-link MTU come from, and
how a router selects these values. Is one of these the router's interface
MRU? Why do you need an off-link MTU? As long as you don't send packets
longer than the router's MRU, then PMTUD will take care of this.
The whole link speed thing makes me a bit uncomfortable. You definitely
want links with a much slower speed to use smaller MTUs, but it seems like
the end hosts are able to make an appropriate decision.
4.3:
It bothers me having switches send this stuff. It seems like an
architectural violation to have a layer 2 device sending layer 3
information.
Since this is broadcast, a single switch can pull down the MTU for an
entire subnet. Is that a good thing?
These are sent out every 5 minutes. If a new device comes up, it might be
operating for 5 minutes (or MAYbe 60 seconds) without this information?
And, it's not even required for a host to listen to it. I'm not sure I
understand the justification for doing this at all.
4.4:
I think there's some promise in this area, but it's currently
underspecified. This section describes the MTU detection message, but
doesn't really say what to do with it. Do you need to get a reply before
using a larger MTU? If you don't get a reply at a given size, then what do
you do? Fall back to the minimum? Probe at other sizes a la 4821?
You forbid sending MTU detection messages more often than once per 60
seconds. I don't see this as being practical (say, on a router interface)
where you may need to send/forward packets to large numbers of hosts that
may all need to be probed individually.
Ultimately I would like to see something done in this area. I might even
volunteer to help. :)
Lastly, I apologize for taking so long to send this out. It was sitting
nearly done, but forgotten, in my drafts folder for about a month. Oops..
-John
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
