Mark,
Many of us have known about this work for a long time now. If
there are certain aspects of it you would like to call to our attention
(e.g., if there is a way for the lower layers to know when the upper
layers are doing PLPMTUD) please send specific details. In the
meantime, I will be turni
Hi All,
Came across this when looking at some other MTU related info.
http://www.psc.edu/~mathis/MTU/#pmtud
There is an ID at
http://www.psc.edu/~mathis/MTU/draft-mathis-plpmtud-00.txt
The BoF slides are at
http://www.psc.edu/~mathis/papers/mtuBOF200303/index.html
Hope this helps,
Mark.
---
I seem to have gotten my wires crossed and thought the I-D cutoff
date was October 31st. No big deal; here are a couple of draft updates
relating to this subject thread that I will be submitting when the I-D
Registrar re-opens for business:
http://www.geocities.com/osprey67/ndiscmtu-01.txt
http:/
Jari Arkko wrote:
Fred Templin wrote:
Yes. But somehow I'm worried about this, particularly when
the MTU size field in ND is 32 bits. Is there any danger that
a false claim of a large MTU size will lead to something
bad happening? Or are we relying on the sender's hardware
to not accept overly
> Yes. But somehow I'm worried about this, particularly when
> the MTU size field in ND is 32 bits. Is there any danger that
> a false claim of a large MTU size will lead to something
> bad happening? Or are we relying on the sender's hardware
> to not accept overly large packets for transmission?
Fred Templin wrote:
Yes. But somehow I'm worried about this, particularly when
the MTU size field in ND is 32 bits. Is there any danger that
a false claim of a large MTU size will lead to something
bad happening? Or are we relying on the sender's hardware
to not accept overly large packets for tra
Jari Arkko wrote:
Erik Nordmark wrote:
> This still has the operational issue of what happens when
> I need extra ports in my office and I get a cheap 4-port hub; neither
> the IT department nor my hosts knows that this box is present and it
> might not support jumboframes.
I'd favor robustness
Erik Nordmark wrote:
No, the existing option is only usable for lowering the MTU used within
a subnet to a value lower than what the "IP over ..." RFC prescribes.
We also need a way to convey the maximum packet size that layer 2
equipment can handle. I think this should be an option that is s
Erik Nordmark wrote:
One case in which data packets could be used as probe packets
is when IPv4 is used as an L2 media for IPv6. In this case, we could
send IPv6-in-IPv4 encapsulated packets with the DF bit NOT set
in the IPv4 header expecting that the decapsulator would send us
some sort of ind
Iljitsch van Beijnum wrote:
On 28 okt 2003, at 0:12, Fred Templin wrote:
> If I hook up two boxes that can do 9000 bytes over ethernet, but the
> switch is 1500 bytes only, I had better make sure those two boxes
> stick to 1500.
Yes, I know. By "negotiate a larger MTU" I mean not only an
init
Erik Nordmark wrote:
> This still has the operational issue of what happens when
> I need extra ports in my office and I get a cheap 4-port hub; neither
> the IT department nor my hosts knows that this box is present and it
> might not support jumboframes.
I'd favor robustness a lot more than opti
On Tue, 28 Oct 2003 11:36:58 +0100 (CET)
Erik Nordmark <[EMAIL PROTECTED]> wrote:
> Just to restate what you are saying differently so that others might understand
> it. Today with have a MTU specified in the IPv6 over foo documents.
> We have an MTU option in router advertisements that can be use
> I'm afraid I'm not bought into this one as being necessary (yet). We know
> from our physical/logical point of attachment what the largest possible
> MTU for the attached L2 media is - this is a given.
That isn't true for Ethernet. A node attaching to an Ethernet has
no (standard) way to tell wh
> No, the existing option is only usable for lowering the MTU used within
> a subnet to a value lower than what the "IP over ..." RFC prescribes.
> We also need a way to convey the maximum packet size that layer 2
> equipment can handle. I think this should be an option that is similar
> to, bu
> One case in which data packets could be used as probe packets
> is when IPv4 is used as an L2 media for IPv6. In this case, we could
> send IPv6-in-IPv4 encapsulated packets with the DF bit NOT set
> in the IPv4 header expecting that the decapsulator would send us
> some sort of indication if it
On 28 okt 2003, at 0:12, Fred Templin wrote:
> If I hook up two boxes that can do 9000 bytes over ethernet, but the
> switch is 1500 bytes only, I had better make sure those two boxes
> stick to 1500.
Yes, I know. By "negotiate a larger MTU" I mean not only an
initial indication of how much the *
Pekka Savola wrote:
On Fri, 24 Oct 2003, Fred Templin wrote:
1) Peer-to-peer wireless (e.g. IEEE 802.11):
On certain wireless media, receiver A can sense QoS metrics (e.g. SNR)
for the packets it receives from senders B and C. If the SNR for B
is strong,
A may wish to inform B that
Erik Nordmark wrote:
If you are probing to determine the initial PMTU, the answer is to send
periodic additional probes, of course. Routes are going to flap, and paths
are going to change - a once-probed MTU cannot be expected to remain
stable for any set length of time.
Did you really mean
On 27 okt 2003, at 19:53, Pekka Savola wrote:
This is also the case for larger MTU's. This problem is nowhere near
non-trivial. Consider e.g. an IPv6 link which is separated by two
Ethernet switches, one which supports jumboframes (MTU=9K) and one
which does not. How would the hosts be able to,
Iljitsch van Beijnum wrote:
> On 25 okt 2003, at 2:51, Fred Templin wrote:
>
>>> So one approach would be something like having a router
>>> advertisement option that asserts "trust us; the L2 can in fact
>>> support 9k" resulting in individual hosts deciding to send out an
>>> option with their
On Mon, 27 Oct 2003, Iljitsch van Beijnum wrote:
> There is no need for any full-blown negotiation. A node can simply
> announce the desired/supported maximum packet size at the time of
> neighbor discovery and be done with it.
Some seem to want a full-blown option as well. Whether there would
Of Fred Templin
Sent: Friday, October 24, 2003 9:06 PM
To: Iljitsch van Beijnum
Cc: [EMAIL PROTECTED]
Subject: Re: "RFC 2461bis" issue: MTU handling
I see (at least) three ways for the neighbor-to-neighbor MTU
negotiation; two were presented in my drafts and the third is
presented b
PROTECTED] On
Behalf Of Fred Templin
Sent: Friday, October 24, 2003 9:06 PM
To: Iljitsch van Beijnum
Cc: [EMAIL PROTECTED]
Subject: Re: "RFC 2461bis" issue: MTU handling
I see (at least) three ways for the neighbor-to-neighbor MTU
negotiation; two were presented in my drafts and th
On 27 okt 2003, at 13:48, Pekka Savola wrote:
If the SNR for B is strong, A may wish to inform B that a larger MTU
(e.g. 1500 bytes) is acceptable. Conversely, if the SNR for C is
weak, A may wish to inform C that a smaller MTU (e.g. 1300 bytes) is
desired.
This kind of dynamic MTU negotiation
On Fri, 24 Oct 2003, Fred Templin wrote:
> 1) Peer-to-peer wireless (e.g. IEEE 802.11):
> On certain wireless media, receiver A can sense QoS metrics (e.g. SNR)
> for the packets it receives from senders B and C. If the SNR for B
> is strong,
> A may wish to inform B that a larger MTU
> > You could use something like an IPv6 NS message that is artificially
> > inflated in size for this as we have discussed in the past. But, it's
> > not
> > a once-and-done deal; if you're going to be probing the MTU you need
> > to do it periodically so that L2 path changes don't result in blac
> If you are probing to determine the initial PMTU, the answer is to send
> periodic additional probes, of course. Routes are going to flap, and paths
> are going to change - a once-probed MTU cannot be expected to remain
> stable for any set length of time.
Did you really mean that?
Clearly there
On 25 okt 2003, at 2:51, Fred Templin wrote:
So one approach would be something like having a router advertisement
option that asserts "trust us; the L2 can in fact support 9k"
resulting in individual hosts deciding to send out an option with
their NS/NA saying "I can support receiving 9k".
Rig
rate spec and leave RFC 2461 untouched...?
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of Fred Templin
> > Sent: Friday, October 24, 2003 9:06 PM
> > To: Iljitsch van Beijnum
> > Cc: [EMAIL PROTECTED]
>
in
> Sent: Friday, October 24, 2003 9:06 PM
> To: Iljitsch van Beijnum
> Cc: [EMAIL PROTECTED]
> Subject: Re: "RFC 2461bis" issue: MTU handling
>
>
> I see (at least) three ways for the neighbor-to-neighbor MTU
> negotiation; two were presented in my drafts and the
I see (at least) three ways for the neighbor-to-neighbor MTU negotiation;
two were presented in my drafts and the third is presented by Iljitsch here.
The methods are:
1) Change RFC 2461 to allow NA messages to include MTU options:
Advantages:
- Unambiguous mechanism for NA's to inform of
Erik Nordmark wrote:
Such a capability would enhance a layer 3 neighbor MTU management
capability, but it isn't required. Operators can simply have routers
annouce an upper limit on the MTU that may be used on a subnet. This
doesn't impede the best case scenario where all the switches support
Pekka Savola wrote:
On Thu, 23 Oct 2003, Iljitsch van Beijnum wrote:
[...]
See http://sd.wareonearth.com/~phil/net/jumbo/ for some links
surrounding this issue.
Yes, and...?
Even if you don't want a separate physical infrastructure, defining a VLAN
is trivial.
Where the L2 supports tha
Erik Nordmark wrote:
Currently, routers can advertise an MTU for a link. That's nice. But
what we really need is a way for hosts to find out the MTU each
individual neighbor can handle. 100 Mbps and slower ethernet interfaces
can typically handle only the standard 1500 byte ethernet MTU, whil
Pekka Savola wrote:
On Thu, 23 Oct 2003, Jun-ichiro itojun Hagino wrote:
[...]
the assumption made in RFC2461 is that the link MTU is constant
over the link, i guess. i don't think it is necessary to make
MTU negotiable between peers, it would complicate too many things.
FWIW, I agre
Itojun,
I disagree with your statement. Two examples where the per-neighbor MTU
negotiation would be very useful:
1) Peer-to-peer wireless (e.g. IEEE 802.11):
On certain wireless media, receiver A can sense QoS metrics (e.g. SNR)
for the packets it receives from senders B and C. If the SNR f
Hello Iljitsch,
An example use case is that on certain multiple-access wireless links
the optimal MTU for a particular neighbor may be proportional to
certain QoS metrics, e.g., the signal to noise ratio sensed at the
receiver's MAC layer.
I submitted a draft proposal back in January 2003 (attach
On Thu, 23 Oct 2003, Iljitsch van Beijnum wrote:
> On 23 okt 2003, at 12:12, Pekka Savola wrote:
> > Even if you don't want a separate physical infrastructure, defining a
> > VLAN is trivial.
>
> Yes, and setting up a new TCP session is even more trivial. But somehow
> people see the value of wr
> Such a capability would enhance a layer 3 neighbor MTU management
> capability, but it isn't required. Operators can simply have routers
> annouce an upper limit on the MTU that may be used on a subnet. This
> doesn't impede the best case scenario where all the switches support a
> good sized
On 23 okt 2003, at 11:08, Erik Nordmark wrote:
[Having hosts discover and use a larger than standard MTU between them]
This might be useful when the L2 doesn't have any MTU limitations.
For instance, with IP over ATM the default MTU is 9k but AAL5 has a 16
bit length field (if I don't misremembe
On 23 okt 2003, at 12:12, Pekka Savola wrote:
Yes, and...?
Even if you don't want a separate physical infrastructure, defining a
VLAN is trivial.
Yes, and setting up a new TCP session is even more trivial. But somehow
people see the value of writing a 150 page specification to do
mobility.
Si
On Thu, 23 Oct 2003, Iljitsch van Beijnum wrote:
[...]
> See http://sd.wareonearth.com/~phil/net/jumbo/ for some links
> surrounding this issue.
Yes, and...?
Even if you don't want a separate physical infrastructure, defining a VLAN
is trivial.
Really, I can't see all that many scenarios where
> Currently, routers can advertise an MTU for a link. That's nice. But
> what we really need is a way for hosts to find out the MTU each
> individual neighbor can handle. 100 Mbps and slower ethernet interfaces
> can typically handle only the standard 1500 byte ethernet MTU, while
> gigabit eth
On 23 okt 2003, at 9:49, Pekka Savola wrote:
the assumption made in RFC2461 is that the link MTU is constant
over the link, i guess. i don't think it is necessary to make
MTU negotiable between peers, it would complicate too many things.
FWIW, I agree with this assumption
On Thu, 23 Oct 2003, Jun-ichiro itojun Hagino wrote:
[...]
> the assumption made in RFC2461 is that the link MTU is constant
> over the link, i guess. i don't think it is necessary to make
> MTU negotiable between peers, it would complicate too many things.
FWIW, I agree with th
> > the assumption made in RFC2461 is that the link MTU is constant
> > over the link, i guess. i don't think it is necessary to make
> > MTU negotiable between peers, it would complicate too many things.
> What would it complicate?
> Obviously nobody is going to force anyone to implem
On 23 okt 2003, at 9:13, Jun-ichiro itojun Hagino wrote:
the assumption made in RFC2461 is that the link MTU is constant
over the link, i guess. i don't think it is necessary to make
MTU negotiable between peers, it would complicate too many things.
What would it complicat
> I'm not sure this should go into a replacement specification for RFC
> 2461, but I'll bring it up anyway:
>
> Currently, routers can advertise an MTU for a link. That's nice. But
> what we really need is a way for hosts to find out the MTU each
> individual neighbor can handle. 100 Mbps and s
I'm not sure this should go into a replacement specification for RFC
2461, but I'll bring it up anyway:
Currently, routers can advertise an MTU for a link. That's nice. But
what we really need is a way for hosts to find out the MTU each
individual neighbor can handle. 100 Mbps and slower ethern
49 matches
Mail list logo
