Comments below...
On 6/10/2016 12:45 AM, Vincent Roca wrote:
...
>>> 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.
--
For this document:
path MTU should indicate the IP packet that can transit a path, and it's
the min of the hop MTUs
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
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.
--
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)
- 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?
>> 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
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
