On 26-aug-2007, at 6:44, John Heffner wrote:
First, I'd like to say that I agree with the goal of being able to
run mixed-MTU subnets.
Excellent!
I'm not yet convinced this draft constitutes a full and practical
solution to the problem.
Let's work on it then.
Based on earlier comments, I'm looking to simplify the next version
of this draft.
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.
Right.
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.
It's meant as a general mechanism. However, in reality, ethernet is
pretty much the only broadcast network in town so that's why I
mention it a lot. I'll see if I can focus more on the generality of
the mechanisms.
The discussion in Section 3 is pretty good, but it might be a bit
long and detailed for this doc.
I agree that this isn't appropriate in a protocol document. However,
these issues have been brought up a lot in the past and I think many
of the earlier arguments were flawed. I wanted to address those flaws
as part of the discussion. I'll see if I can spin the CRC details off
to a separate document at some point.
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.
From earlier in the document:
Allowed MTU:
The maximum MTU allowed administratively.
Off-link MTU:
The maximum packet size that is appropriate for communicating
with
off-link correspondents.
The allowed MTU is the maximum MTU the administrator will allow. So
for instance, when a switch only supports 3000-byte packets, the
administrator can set the allowed MTU to 3000 to make sure the
optimum packet size is used without unnecessary probing at larger sizes.
The idea behind the off-link MTU is that hosts can use this value to
base their TCP MSS and packet size to off-link destinations on so
that PMTUD and possible problems related to it can be avoided easily
while it's still possible to use large packets on the local subnet.
Do you think this is unnecessary?
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.
So do you think this should be removed? If the hosts don't make the
right decision on their own and MTU size at a certain speed is a
concern (i.e., VoIP jitter), this means that it's either necessary to
advertise a conservative MTU for all speeds, or touch all host
configurations.
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?
Although this could be useful if widely implemented, I think you're
right and it's probably best to remove this part. If switches really
want to advertise something they can always send out an RA with a
lifetime of 0 so the switch won't be used as a default router.
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?
I'll add text.
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.
It's 60 seconds or until you get a reply back. What I want is to
avoid generating large numbers of oversized packets, which could
possibly trigger undesired behavior on devices that can't handle the
larger packets. Maybe make this something that can be set
administratively and suggest a default of 60 seconds?
Ultimately I would like to see something done in this area. I
might even volunteer to help. :)
Any help will be much appreciated, text, code, ASCII art, test
devices that support really large MTUs... :-)
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
