Subject: [Int-area] Comments on draft-van-beijnum-multi-mtu-02

From: Dave Thaler <[email-masked]>
Date: Mon, 10 Mar 2008 20:17:17 -0700

1) Section 3.2 should motivate better why Path MTU Discovery doesn't already solve this problem.  Certainly one issue is that the router has to communicate a value larger than the link MTU in the IP-over-foo document, no question about that.  But once that is done, why do you need the ND probing mechanism as opposed to PMTU discovery?  As pointed out in 3.2 already, the main scenario for this draft is on-link communication (since anything else will be limited by the minimum path MTU which will generally be a standard number), in which case ICMP blocking isn't really an issue, and PMTU Discovery can already discover a per-neighbor MTU that's lower than the link MTU.  So more motivating text seems warranted.

2) Section 4.1: Why put the number "600 Mbps" in the doc?  Seems like this number would become obsolete over time, and it would just just as easy to put the threshold in the option.

3) Section 4.5 says:
> However, the node MUST be prepared to receive packets up to the
> SAFEMTU size.

Per RFC 2460, it is not a requirement that a node be able to receive packets larger than 1500 bytes.  This MUST seems to change that without explicitly saying so.

I also have a couple minor editorial comments which I will just send to the author.

-Dave
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 Mar 2008 12:33:55 -0400

On 10 mrt 2008, at 23:17, Dave Thaler wrote:

> 1) Section 3.2 should motivate better why Path MTU Discovery doesn't  
> already solve this problem.  Certainly one issue is that the router  
> has to communicate a value larger than the link MTU in the IP-over- 
> foo document, no question about that.  But once that is done, why do  
> you need the ND probing mechanism as opposed to PMTU discovery?

RFC 1191 PMTUD requires that hosts receive ICMP too big messages. In  
order to be able to generate those, a router (I guess a switch could  
also do it) must first successfully receive a packet, then determine  
that it is too big to be forwarded and then it can return the too big  
message.

On a link with variable MTUs the second step is not possible without  
additional communication of per-destination MTUs, and even then  
"invisible" layer 2 devices can get in the way. These layer 2 devices  
can't do step 1 because of hardware limitations.

However, it is possible to do RFC 4821 style PMTUD rather than the  
more explicit mechanisms, but this has a number of limitations, mostly  
that it works at the transport layer so that you need to implement it  
in each transport protocol and that it's not possible to determine  
whether a given host or a given session supports RFC 4821 or not.

> As pointed out in 3.2 already, the main scenario for this draft is  
> on-link communication (since anything else will be limited by the  
> minimum path MTU which will generally be a standard number), in  
> which case ICMP blocking isn't really an issue, and PMTU Discovery  
> can already discover a per-neighbor MTU that's lower than the link  
> MTU.  So more motivating text seems warranted.

I'll see if I can come up with something. You are right that this is a  
subnet-local thing (hence the title), although there are of course  
effects that transcend the local subnet.

> 2) Section 4.1: Why put the number "600 Mbps" in the doc?  Seems  
> like this number would become obsolete over time, and it would just  
> just as easy to put the threshold in the option.

600 is just below 622 Mbps OC-12 which makes for a good cutoff and it  
also works out nicely for a future extension that I have in mind. (A  
common jumboframe size is 9000 bytes = 6 x 1500 so at 600 Mbps with 9k  
delay is the same as 100/1500.)

I don't have a problem with putting the value in the protocol but  
there doesn't seem to be much advantage to that. Except maybe at some  
point in the future where we want new hosts to use 32 MB packets while  
slow 802.11xyz hosts operating at just 8 Gbps should use 512 kB  
packets...

With 1 Gbps or higher delay over the internet is almost exclusively  
determined by the length of the path (speed of light) so at gigabit  
speeds packets of sizes that we currently consider reasonable (64k or  
smaller) aren't a problem. At 10 Mbps, using 9k packets can hurt delay/ 
jitter sensitive applications, this is what administrators should be  
able to avoid.

> Per RFC 2460, it is not a requirement that a node be able to receive  
> packets larger than 1500 bytes.  This MUST seems to change that  
> without explicitly saying so.

The draft also specifies what a node should do if it can't conform to  
the MUST, which is a bit odd. I'll try to find a way to have this make  
more sense.

> I also have a couple minor editorial comments which I will just send  

Got those. Thanks for the comments!

Iljitsch

---

From: Dave Thaler <[email-masked]>
Date: Tue, 11 Mar 2008 11:38:50 -0700

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2008 12:34 PM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: Re: Comments on draft-van-beijnum-multi-mtu-02
>

Right.  RFC 2461 states:
"If the bridges do not generate ICMP
Packet Too Big messages, communicating nodes will
be unable to use Path MTU to dynamically determine
the appropriate MTU on a per-neighbor basis.  In
such cases, routers use the MTU option to specify
the maximum MTU value that is supported by all
segments."

Note the specific clause that suggests that bridges can generate ICMP
too big messages.

> can't do step 1 because of hardware limitations.

I don't know what you mean about "can't do step 1".  Can you elaborate?

[...]

-Dave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 Mar 2008 14:51:33 -0400

> Note the specific clause that suggests that bridges can generate ICMP

I've seen them do IP(v4) fragmentation, too.

> I don't know what you mean about "can't do step 1".  Can you  

Following topology:

H1----X----H2

In the current situation where X is a router, then X can by definition  
receive the largest packets that H1 can send because H1 and X MUST use  
the same MTU on their common subnet. If then the subnet towards H2  
uses a smaller MTU X can return a too big to H1.

For ethernet, the problem doesn't arise today because the MTU is  
always 1500 bytes.

If we now go to multi MTU subnets, H1 could send a packet that is  
larger than X can receive if H1 happens to have a larger MTU than X.  
This means that in that case X can't successfully receive the packet,  
which is of course a prerequisite for generating too big messages.
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area