Hello Joe, Here also, sorry for the delay!
>>>> I also clarified the case of encapsulation header size that is deducted. >>> It's worth noting throughout that MTU is defined as the size of the payload. >> Yes but there are two notions of payloads depending on the point of view. >> Figure 10 can be useful: >> inner packet payload => iD >> tunnel link packet's payload => iH+iD > > We should never be concerned with the E2E payload, i.e., iD. All we need > to know is the size of the entire E2E message that a link (or tunnel, > which is a link) must transfer. > > However, I see the confusion here. > > As context: > TCP MSS describes the payload, exclusive of IP and TCP headers and > their options (RFC6991) > > ICMPv4 frag needed and IPv6 PTB indicates "next-hop MTU" as the > largest IP packet that the next-hop link can forward without on-path > fragmentation (RFC1191, RFC4443) > > So MTU generally refers to the *payload* that a link or path can transfer. I'm 100% okay. My comment is just that "payload" is misleading if the context is not perfectly defined (transport vs. network vs. link, with vs. without tunnels). > -- > > For this document: > > path MTU should indicate the IP packet that can transit a path, and it's > the min of the hop MTUs **largest** IP packet... > hop MTU should indicate the one-hop version of the path MTU, i.e., the > largest IP packet that can *transit* over a link (it does NOT include > the link headers) > these are the ones that are 64 or 1280 rather than "it does NOT include..." I'd prefer: "this network layer definition does not consider link-layer headers" > link MTU should be defined more clearly as the link-layer packet that > can transit the link > these must transit (64 or 1280) + link headers > > We should use two different terms now: > > tunnel hop MTU: the largest IP packet that can transit (inside) a tunnel > > tunnel link MTU: the largest (encapsulated) packet that can transit > between ingress and egress (in the current doc, we call this the tunnel MTU) > > We should add a new term: > > E2E MTU: the largest IP message that can transit between a source and > destination, which is 576/1500 at a minimum. > > And yes, a new figure can help explain all of this more clearly. Great. Those definitions will help a lot. > -- > > With regard to your suggestions: > > - I don't think it's useful to define link MTU as 64/1280 because it > isn't; it's those values + link (as noted above) That's a good reason indeed ;-) With the updated definitions, there won't be any risk of mistake. > - the reassembly MTU definition needs to explain that it's at the level > being reassembled, NOT the payload of the reassembled message. at IP > receivers, this is the E2E MTU but not the path MTU. at tunnel egress, > this is the tunnel link MTU (i.e., the E2E MTU between ingress and egress). > > Does that make more sense? Yes, perfectly clear. >>> I think we do need another term for the path MTU between the egress and >>> ingress but NOT inside the tunnel. I prefer to just call that the PMTU >>> between the ingress and egress, though. >> Okay, this is the regular IP vision of PMTU. If we need it, we can define it. > > See above; E2E MTU between ingress and egress is different than any PMTU. > > Joe Thanks for the updated definitions. Cheers, Vincent
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
