Subject: [Int-area] Comments on draft-ietf-intarea-tunnels-00.txt

From: Pat Thaler <[email-masked]>
Date: Thu, 13 Nov 2014 17:57:16 +0000

Comments from an Ethernet point of view.

3.1 MTU discovery mentions sending 1200-1400 bytes rather than 1500 to allow for tunnel overhead. 1500 bytes seems like a reference to the Ethernet maximum frame size (1518 with the MAC Header and CRC allows 1500 octets of payload).  In this context, the Frame format extension to IEEE Std 802.3 originally completed in the amendment IEEE Std 802.3as-2006  should probably be mentioned.

This added an additional maximum frame size of 1982 octets (2000 with the MAC header and CRC) to Ethernet to support "envelope frames" - frames  encapsulated with additional headers and trailers for purposes such as tunneling, security, etc.  This allows for encapsulation protocols adding up to 482 octets without requiring fragmentation (assuming that the original senders limit themselves to 1500 octet frames as intended.

Support for the larger frame size is common so generally 1500 byte packets plus a reasonable amount of encapsulation should go through.

The draft would benefit from a further discussion of what difference between original and envelop maximum packet size should be to avoid fragmentation with common envelope protocols. Of course there is no absolute maximum but it would be helpful to look at some useful sizes - or at least a list of  added lengths for some of the common protocols.

3.2.4 GigE bursting isn't a good analogy for packing for a number of reasons.

GigE bursting is done along with the physical layer coding where each byte is encoded into a 10 bit transmission code. That allows for control codes (ones that don't map to an 8-bit data value). A carrier extend control code is used to indicate an inter-packet gap that doesn't drop carrier. There is no packing of small packets into one big  packet and no need for data structures (e.g. length fields) to indicate when one packet ends and another starts.

GigE bursting isn't subject to maximum packet size restrictions because it isn't building a packet. It is a mechanism to extend transmission when operating CSMA/CD over a shared media with collision detection time longer than minimum packet size. So if a packet ends before the collision detection window, carrier extension is done for at least an IPG and if the collision detection window still isn't over, a new packet can be started even if the window will close before that packet ends. So the transmission can continue for a collision window plus a maximum packet length minus one byte (i.e. when a maximum size packet is started just before the window ends.

GigE bursting is used over a shared medium (i.e. one layer 2 hop) so it can join any packets into a  burst. All other ports on the shared media see the burst and receive the packets meant for them. Therefore, there are no constraints on what packets can be in a burst. It just sends the next packet. On the other hand, a tunnel encapsulation would have to pack only packets going to the same destination. And if the tunnel encapsulation isn't going to create misordering, once it gets to an inner packet too long to fit in the rest of the tunnel packet, it would have to terminate the tunnel packet. So packing is only useful when there is a run of short packets going to the same destination arriving reasonably close together.

GigE bursting was designed when it was thought that there would be repeaters connecting GigE ports into a shared network. Switches (e.g. IEEE 802.1 bridges) displaced repeaters in the market about the time it was finishing. While there were some prototype GigE repeaters built, I don't think any went into production and there was little or no use of GigE bursting in other than experimental deployments.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Nov 2014 09:35:46 -1000

On 13 Nov 2014, at 7:57, Pat Thaler <[email-masked]> wrote:

> 3.1 MTU discovery mentions sending 1200-1400 bytes rather than 1500 to allow for tunnel amendment IEEE Std 802.3as-2006  should probably be mentioned.

> This added an additional maximum frame size of 1982 octets (2000 with the MAC header fragmentation (assuming that the original senders limit themselves to 1500 octet frames as intended.

Ah, this is also useful for draft-van-beijnum-multi-mtu.

A question: does this size accommodate for the VLAN ID? I.e., is it likely that some switches will forward 1978-byte IP packets instead?

Thanks,

Iljitsch

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 13 Nov 2014 23:16:54 +0000

Hi, the current "Internet Cell Size" that is configured by the vast majority of hosts in
the Internet is still 1500. So, if we ensure that everything up to and including 1500 bytes
gets through the tunnel (i.e., even if a little bit of fragmentation is needed) then larger
packets can  be admitted and allowed to sink or swim on their own. See Section 3.12
of draft-templin-aerolink for the specification, which needs to be rolled into
'draft-ietf-intarea-tunnels'.

Thanks - Fred
[email-masked]

From: Int-area [mailto:[email-masked]] On Behalf Of Pat Thaler
Sent: Thursday, November 13, 2014 9:57 AM
To: [email-masked]
Subject: [Int-area] Comments on draft-ietf-intarea-tunnels-00.txt

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 13 Nov 2014 23:21:33 +0000

Hi Iljitsch,

Correct me if I'm wrong, but your proposal is to probe for per-neighbor MTU
sizes for neighbors on the same link, correct? Which means that this might
need to happen independently on each link in the path?

MTU probing for packet sizes larger than 1500 bytes is an end-to-end function,
and not a hop-b y-hop function. RFC4821 already specifies the method for
end-to-end MTU probing.

Thanks - Fred

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Thursday, November 13, 2014 11:36 AM
> To: Pat Thaler
> Cc: [email-masked]
> Subject: Re: [Int-area] Comments on draft-ietf-intarea-tunnels-00.txt
> 
> > This added an additional maximum frame size of 1982 octets (2000 with the MAC header fragmentation (assuming that the original
> senders limit themselves to 1500 octet frames as intended.
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Nov 2014 13:56:33 -1000

On 13 Nov 2014, at 13:21, Templin, Fred L <[email-masked]> wrote:

> your proposal is to probe for per-neighbor MTU sizes for neighbors on the same link, correct? Which means that this might need to happen independently on each link in the path?

Yes and yes.

> and not a hop-b y-hop function. RFC4821 already specifies the method for

You still need path MTU discovery even when my variable subnet MTU system is used, because a host only "sees" the MTU of the local subnet.

In a world where RFC 4821 would be widely implemented you could just send the largest packets that your interface supports and not worry about packets being lost because they're too big for the next hop host or router, or the switch in the middle.

However, as far as I can few systems if any use RFC 4821 for TCP and I've certainly never heard of UDP-based applications implementing it.

With my system there is explicit probing on local subnets so routers know the MTU for a next hop and can generate the "too bigs" that regular PMTUD depends on to work. In the presence of RFC 4821 the system is still helpful because it's much more efficient:

- detect the MTU of the router once rather than for each remote session
- avoid sending unsupported large packet sizes over longer distances
- waiting for an end-to-end timeout can often be avoided

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Nov 2014 00:22:45 +0000

Hi Iljitsch,

> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Thursday, November 13, 2014 3:57 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: PMTUD, was: Re: [Int-area] Comments on draft-ietf-intarea-tunnels-00.txt
> 
> > your proposal is to probe for per-neighbor MTU sizes for neighbors on the same link, correct? Which means that this might need to
> happen independently on each link in the path?
> 
> Yes and yes.
> 

RFC1981 says:

   "Note that Path MTU Discovery must be performed even in cases where a
   node "thinks" a destination is attached to the same link as itself.
   In a situation such as when a neighboring router acts as proxy [ND]
   for some destination, the destination can to appear to be directly
   connected but is in fact more than one hop away."

That means that RFC1981 PTB messages might come from a switching element
within the link path from the ingress to egress, and so standard ICMPv6 PMTUD
messaging is supported.

> In a world where RFC 4821 would be widely implemented you could just send the largest packets that your interface supports and not
> worry about packets being lost because they're too big for the next hop host or router, or the switch in the middle.

Not quite; in an RFC4821 world you start conservatively then "sneak up" on larger
sizes through probe->advance->probe->advance->etc. progressions. You would
never start out by sending the largest possible sizes before probing.

> However, as far as I can few systems if any use RFC 4821 for TCP and I've certainly never heard of UDP-based applications

What we need to come out of this with is a BCP recommendation for the
intarea-tunnels draft. That BCP should say that "hosts that send packets
larger than 1500 bytes SHOULD use RFC4821". 1500 bytes then becomes
the RFC4821 threshold.

> With my system there is explicit probing on local subnets so routers know the MTU for a next hop and can generate the "too bigs" that
> regular PMTUD depends on to work. In the presence of RFC 4821 the system is still helpful because it's much more efficient:

Again, any host that sends packets larger than 1500 SHOULD use RFC4821. If
we come out of this with a BCP recommendation like that we do not need to
do any additional hop-by-hop probing.

> - detect the MTU of the router once rather than for each remote session

Subnetwork paths can change, however, so it is not sufficient to probe once
and then fix the size once and for all.

> - avoid sending unsupported large packet sizes over longer distances

With the correct BCP in place, large packets should either be the probes
themselves or regular data packets that are no larger than the largest
successful probe size. In both cases, the link should just let them through.

> - waiting for an end-to-end timeout can often be avoided

RFC4821 nodes do not wait for end-to-end timeouts. They keep sending
at the smaller packet sizes until a larger size has been discovered.

Thanks - Fred

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Nov 2014 15:53:58 -1000

Hi Fred,

> within the link path from the ingress to egress, and so standard ICMPv6 PMTUD

I don't see how you can reach that conclusion. The situation where too bigs are generated is when a layer 3 or layer 2 device receives a packet on a port that obviously supports the packet size in question, but then that packet is too large to transmit on the outgoing port. For routers this is a fairly routine situation, as they connect to different types of links. But on switches, typically (universally, even?) all ports support the same MTU.

So in theory it's possible that a switch would implement enough IPv4 and/or IPv6 to do this, but in practice it just doesn't happen. I've only once see a multilayer switch handle packet size differences when operating at layer 2 (and in that case it fragmented the packets).

> in an RFC4821 world you start conservatively then "sneak up" on larger
> sizes through probe->advance->probe->advance->etc. progressions.

Of course. I didn't mean to suggest anything to the contrary.

> larger than 1500 bytes SHOULD use RFC4821". 1500 bytes then becomes

Disagree. There shouldn't be any magic packet sizes. PMTUD issues are typically caused by MTUs < 1500, not MTUs > 1500 in any event, so you wouldn't want to let people with 1500 MTUs off the hook.

> and then fix the size once and for all.

Probing happens once and after that a node keeps track of where it sends large packets and then makes sure it receives either large packets or acknowledgments to make sure everything is still ok.

The most obvious case where a path would stop supporting the current jumboframe size would be in this situation:

A - 9000 - B
|                 |
9               9
0               0
0               0
0               0
|                 |
C - 1500 - D

Then assume spanning tree disables the C - D link so all paths support 9000 bytes. Then the link A - B goes down and suddenly A - B, A - D and B - C can only communicate at 1500 bytes.

> at the smaller packet sizes until a larger size has been discovered.

Right, with fast retransmit and enough send/receive buffer space this wouldn't impact the progress of the session.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Nov 2014 02:37:52 +0000

Hi Iljistsch,

> Sent: Thursday, November 13, 2014 5:54 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: PMTUD, was: Re: [Int-area] Comments on draft-ietf-intarea-tunnels-00.txt
> 
> Hi Fred,
> 
> I don't see how you can reach that conclusion. The situation where too bigs are generated is when a layer 3 or layer 2 device receives a
> packet on a port that obviously supports the packet size in question, but then that packet is too large to transmit on the outgoing port.
> For routers this is a fairly routine situation, as they connect to different types of links. But on switches, typically (universally, even?) all
> ports support the same MTU.
>
> So in theory it's possible that a switch would implement enough IPv4 and/or IPv6 to do this, but in practice it just doesn't happen.

In a tunnel, when treated as a "link", the switching elements in the path are ordinary
IPv6/IPv4 routers. They can generate what amounts to an L2 PTB message, which gets
received by the tunnel ingress and translated into an L3 PTB message. Or, if the message
gets lost, the original host (presumably doing RFC4821) simply stops sending big packets.

> only once see a multilayer switch handle packet size differences when operating at layer 2 (and in that case it fragmented the
> packets).

Fragmentation for packets that are no larger than 1500, yes, and only used when
needed. "Take care of the smalls, and let the bigs take care of themselves".

> Of course. I didn't mean to suggest anything to the contrary.

OK.

> Disagree. There shouldn't be any magic packet sizes. PMTUD issues are typically caused by MTUs < 1500, not MTUs > 1500 in any
> event, so you wouldn't want to let people with 1500 MTUs off the hook.

But, there already is a HARD magic size - 1280. I am proposing a SOFT magic size
of 1500. 1500 is the size that most hosts expect to work. I am simply suggesting
that we fulfill that expectation.

> Probing happens once and after that a node keeps track of where it sends large packets and then makes sure it receives either large
> packets or acknowledgments to make sure everything is still ok.

What you are describing is a classic end-to-end consideration; not hop-by-hop.

> Then assume spanning tree disables the C - D link so all paths support 9000 bytes. Then the link A - B goes down and suddenly A - B, A -
> D and B - C can only communicate at 1500 bytes.

How are the nodes going to be agile enough to detect the path MTU decrease;
by continually sending lots of probes? Or, by getting some kind of L2 PTB
indication? Again, you are trying to do something hop-by-hop which should
be handled end-to-end.

> Right, with fast retransmit and enough send/receive buffer space this wouldn't impact the progress of the session.

I meant that RFC4821 probing is performed separately from the routine TCP
segment transmission process. The TCP will not start sending larger segments
until the larger size has been successfully probed.

Thanks - Fred

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Nov 2014 17:11:56 -1000

Hi again Fred,

> On 13 Nov 2014, at 16:37, Templin, Fred L <[email-masked]> wrote:

> IPv6/IPv4 routers.

Hm, yes, but when discussing "switches" I wouldn't normally include IP routers forwarding tunneled packets.

> indication?

A node tracks whether it sends large packets to a given neighbor and whether it receives them. If the node receives large packets during an interval, then everything is good. If the node didn't send any large packets, there's also no issue. If the node did send large packets but didn't receive any, it's time to start worrying. But maybe there was an outgoing data transfer so everything is ok, the other side simply didn't have enough data to send to fill up a large packet. This situation can be recognized by monitoring TCP state. But if it looks like large packets may be disappearing into a black hole, it's time to send a probe.

> Again, you are trying to do something hop-by-hop which should
> be handled end-to-end.

The thing I focussed on here is the ability to turn on jumboframes on a node-by-node basis without having to worry about all hosts and routers on the same subnet having the same MTU configured. So the mechanism is intended to be run on a local subnet. It even uses the TTL=255 trick to make sure packets coming in from far away are rejected.

However... there's no reason the probing couldn't work over multiple hops. I thought about allowing this, but I decided against it because sending a whole bunch of large probe packets in relatively quick succession may not be appropriate when a system is connected over a slow link.

> segment transmission process.

Well:

   With TCP the only approach is to send additional
   payload data in an over-sized segment.  There are at least two
   variants of this approach, discussed in Section 10.1.

The RFC allows for two approaches: the one I assumed (using normal data) and another approach where duplicate data is used to probe so if a probe is lost this has no impact on the progress of the TCP session.

Iljitsch

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Nov 2014 05:17:03 +0000

Hi Iljitsch,

> Sent: Thursday, November 13, 2014 7:12 PM
> To: Templin, Fred L
> Cc: [email-masked]

Well, tunnels aside, imagine the IETF1981 example of a "link" that is actually extended
through proxies, where any proxy on the path can return a PTB.

> A node tracks whether it sends large packets to a given neighbor and whether it receives them. If the node receives large packets
> during an interval, then everything is good. If the node didn't send any large packets, there's also no issue. If the node did send large
> packets but didn't receive any, it's time to start worrying. But maybe there was an outgoing data transfer so everything is ok, the other
> side simply didn't have enough data to send to fill up a large packet. This situation can be recognized by monitoring TCP state. But if it
> looks like large packets may be disappearing into a black hole, it's time to send a probe.

So, you want to put "smarts" into network middleboxes - is it the end of end-to-end?

> The thing I focussed on here is the ability to turn on jumboframes on a node-by-node basis without having to worry about all hosts
> and routers on the same subnet having the same MTU configured. So the mechanism is intended to be run on a local subnet. It even
> uses the TTL=255 trick to make sure packets coming in from far away are rejected.

Ok, I will pop my head up out of the NBMA tunnel virtual link "subnet" that I
have been coming from and take the example of a physical L2 link like a large
switched Ethernet campus LAN. In that case, you know for fact that all nodes
can accept 1500 (unless some have misconfigured their interface MTUs). If
a node that connects to the link has a 9K MTU, however, then why can't it
just blindly admit packets up to 9KB into the switched infrastructure and let
them either make it to the L2 neighbor or get dropped somewhere along
the way at a restricting link segment?

If we are able to establish the BCP that hosts that send packets larger than
1500 SHOULD use RFC4821, then we have an end-to-end assurance that
the hosts will be able to converege to an appropriate size without any
assist from the link itself.

> However... there's no reason the probing couldn't work over multiple hops. I thought about allowing this, but I decided against it
> because sending a whole bunch of large probe packets in relatively quick succession may not be appropriate when a system is
> connected over a slow link.

I am thinking about this more regarding the diagram from your last message,
and it seems what you are re-creating is the old FDDI/Ethernet bridging
problem from back in the 1980's. They wanted to do transparent bridging
between 4500 and 1500 L2 link segments, but there was no way to do
path MTU discovery across such a bridged infrastructure. We now have
RFC4821, which may have actually saved the day several decades ago.

> The RFC allows for two approaches: the one I assumed (using normal data) and another approach where duplicate data is used to
> probe so if a probe is lost this has no impact on the progress of the TCP session.

I understand the scenario you are concerned with, but I still think it is a job
for end-to-end.

Thanks - Fred

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Nov 2014 21:13:39 -1000

Fred,

On 13 Nov 2014, at 19:17, Templin, Fred L <[email-masked]> wrote:

>> A node tracks

> So, you want to put "smarts" into network middleboxes - is it the end of end-to-end?

Not a lot of smarts, but yes, some, mostly in the hosts at the edges but also in routers. There is no requirement that routers track TCP state, but they would have to track which neighbors they send large packets to and from which neighbors they receive them in order to not have to send probes at regular intervals.

> the way at a restricting link segment?

Sure you can do that, but then your DNS packets with EDNS0=4k aren't going to make it, even with RFC 4821 support. And suppose two hosts support 9k but switches or routers in between don't, then those two hosts won't be able to communicate unless they both implement RFC 4821.

A quick search shows some info on Linux and Windows implementations, but it looks like Windows may not have it fully enabled by default.

With my system, you simply run a little program on each host (I guess that's harder to do on routers) and then all these problems go away, with no need to wait until Microsoft, Apple or Linus decide to add new features to their networking stacks.

> assist from the link itself.

I have no problem advocating for RFC 4821 (and not just on > 1500 interfaces) but don't forget that this really only addresses TCP, and not, for instance, tunnel packets.

Also, although RFC 4821 is effective, it's not very efficient. Regular PMTUD, when it works, arrives at the correct path MTU much faster because of explicit feedback from routers along the way, where RFC 4821 has to stumble in the dark and send many probes to reach the same result. So even when RFC 4821 is widely supported, it's useful to have feedback about the path MTU from routers and the next hop MTU from the multi MTU subnet system that I'm proposing.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Nov 2014 22:00:10 +0000

Hi Iljitsch,

> Sent: Thursday, November 13, 2014 11:14 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Not a lot of smarts, but yes, some, mostly in the hosts at the edges but also in routers. There is no requirement that routers track TCP
> state, but they would have to track which neighbors they send large packets to and from which neighbors they receive them in order
> to not have to send probes at regular intervals.
> 
> Sure you can do that, but then your DNS packets with EDNS0=4k aren't going to make it, even with RFC 4821 support.

Again, the BCP recommendation is that hosts that send packets larger than 1500
SHOULD use RFC4821. Either that, or fragment the packet into fragments no larger
than 1280 bytes each if there is no choice but to send big packets (i.e., the EDNS0
case).

> And suppose
> two hosts support 9k but switches or routers in between don't, then those two hosts won't be able to communicate unless they both
> implement RFC 4821.

RFC4821 does not require that both hosts implement it. Only the sending host needs
to implement it, and the receiving host simply sends ordinary acknowledgements.
Again, we make the BCP threshold 1500 bytes and everything should be OK.

> A quick search shows some info on Linux and Windows implementations, but it looks like Windows may not have it fully enabled by

Right, we need to fix that.

> With my system, you simply run a little program on each host (I guess that's harder to do on routers) and then all these problems go
> away, with no need to wait until Microsoft, Apple or Linus decide to add new features to their networking stacks.

If you can run your little program on each host then you can run RFC4821 on each
host. And, running little programs on routers can result in a large headache.

> not, for instance, tunnel packets.

UDP apps can also do RFC4821-style probing. And tunnels can too, per Section 3.12
of draft-templin-aerolink.

> Also, although RFC 4821 is effective, it's not very efficient. Regular PMTUD, when it works, arrives at the correct path MTU much faster
> because of explicit feedback from routers along the way, where RFC 4821 has to stumble in the dark and send many probes to reach
> the same result. So even when RFC 4821 is widely supported, it's useful to have feedback about the path MTU from routers and the
> next hop MTU from the multi MTU subnet system that I'm proposing.

Doesn't your approach also have to start small and probe upwards the same as RFC4821,
possibly resulting in many probes?

Thanks - Fred

---

From: Bill Fenner <[email-masked]>
Date: Fri, 14 Nov 2014 12:46:43 -1000

On Thu, Nov 13, 2014 at 7:57 AM, Pat Thaler <[email-masked]> wrote:

> 3.1 MTU discovery mentions sending 1200-1400 bytes rather than 1500 to
> allow for tunnel overhead. 1500 bytes seems like a reference to the
> Ethernet maximum frame size (1518 with the MAC Header and CRC allows 1500
> octets of payload).  In this context, the Frame format extension to IEEE
> Std 802.3 originally completed in the amendment IEEE Std 802.3as-2006
> should probably be mentioned.
>
>
>
> This added an additional maximum frame size of 1982 octets (2000 with the
> MAC header and CRC) to Ethernet to support “envelope frames” – frames
>  encapsulated with additional headers and trailers for purposes such as
> tunneling, security, etc.  This allows for encapsulation protocols adding
> up to 482 octets without requiring fragmentation (assuming that the
> original senders limit themselves to 1500 octet frames as intended.
>
>
>
> Support for the larger frame size is common so generally 1500 byte packets
> plus a reasonable amount of encapsulation should go through.
>

I mentioned this at the mic in the meeting, but thought it would be useful
to mention on the list.  We have brand-new equipment for this IETF meeting
network, and it came with a default 1500 byte MTU.  Larger MTUs have been
configurable for a long time, including before the IEEE said that it was
OK, but experience says that even brand-new equipment can ship with a
default setting of 1500.

This means that, IMO, this statement has to include the caveat that every
switch and router along the path may need to be configured explicitly to
handle the larger MTU.

  Bill

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Nov 2014 14:16:14 -1000

On 14 Nov 2014, at 12:46, Bill Fenner <[email-masked]> wrote:

> I mentioned this at the mic in the meeting, but thought it would be useful to mention on the list.  We have brand-new equipment for this IETF meeting network, and it came with a default 1500 byte MTU.  Larger MTUs have been configurable for a long time, including before the IEEE said that it was OK, but experience says that even brand-new equipment can ship with a default setting of 1500.

Is this the IP MTU or the Ethernet frame size?

It's fairly routine for switches (less so for Wi-Fi gear, AFAIK) to have some sort of jumboframe support enabled out of the box, as this doesn't cause any interoperability issues.

But if you're talking about the IP MTU, then obviously the vendor has implemented RFC 894 (despite that being the first ever April 1st RFC) and RFC 2464.

> This means that, IMO, this statement has to include the caveat that every switch and router along the path may need to be configured explicitly to handle the larger MTU.

IP expects all nodes on a subnet to use the same MTU size. So using something larger than 1500 on Ethernet requires an administrator to explicitly configure this on all nodes connected to the subnet. The idea behind my draft is to be able to automatically use a larger size if the hardware supports it because the nodes talk to each other to make sure that the larger size is supported on both ends and the packet actually make it.

I'll respond to more of the issues brought up at the session and on the list later.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 16 Nov 2014 09:54:51 -0800

Fred,

On 14 Nov 2014, at 12:00, Templin, Fred L <[email-masked]> wrote:

>> because of explicit feedback from routers along the way, where RFC 4821 has to stumble in the dark and send many probes

> Doesn't your approach also have to start small and probe upwards the same as RFC4821, possibly resulting in many probes?

That is possible, yes.

However: these probes will be on a local subnet and thus typically happen quickly. Also, if a switch isn't a bottleneck, then no probing for MTU size is necessary, just a test packet to confirm that the smallest size supported by the two sides make it through. Even if a switch in the middle is a bottleneck, it may be possible to avoid sending many probes by using the MTU found for another neighbor previously as a hint. (I.e., if neighbor A says it does 9k and only 5k packets make it, then test with 5k immediately towards neighbor B.) And there's no need to rediscover the MTU for destinations reachable through the same next hop.

Iljitsch

---

From: Bill Fenner <[email-masked]>
Date: Tue, 25 Nov 2014 13:48:25 -0500

On Fri, Nov 14, 2014 at 7:16 PM, Iljitsch van Beijnum <[email-masked]>
wrote:

> > I mentioned this at the mic in the meeting, but thought it would be
> useful to mention on the list.  We have brand-new equipment for this IETF
> meeting network, and it came with a default 1500 byte MTU.  Larger MTUs
> have been configurable for a long time, including before the IEEE said that
> it was OK, but experience says that even brand-new equipment can ship with
> a default setting of 1500.
>

This was the Ethernet frame size.  We know because a bug caused the
hardware to be mis-programmed with 1514 instead of 1518 and we couldn't
pass q-tagged frames; if the default was larger we wouldn't have noticed
because it would have just eaten into the allowed tunneling overhead.

> It's fairly routine for switches (less so for Wi-Fi gear, AFAIK) to have
> some sort of jumboframe support enabled out of the box, as this doesn't
> cause any interoperability issues.
>

Some do, some don't.  It's far from universal.

To be clear, I wasn't talking about your draft; I was just trying to
address Pat's statement that you can rely on the Ethernet frame size being
1982 - I'm pretty sure that you can rely on *support* for 1982 (or more)
but it's not unlikely that you have to explicitly configure the Ethernet
max frame size, and it's nearly guaranteed that you have to explicitly
configure the IP MTU.

  Bill