Hi, Linda,
On 10/6/2016 4:36 PM, Linda Dunbar wrote:
>
> Joe,
>
>
>
> I strongly agree with what you said “A link MTU is different from a
> path MTU”.
>
>
>
> A Tunnel MTU is more like “path MTU” because
>
> - the Tunnel MTU is the minimum of all the links’ MTU that
> the “tunnel” traverse,
>
A link MTU is the largest IP packet that can traverse the link (i.e.,
without needing to be fragmented to go over the link).
A tunnel MTU, like a link MTU, is the largest IP packet that can
traverse the tunnel or link layer without needing to be fragmented
FIRST, which is one of two things, whichever is larger:
1. - the min of the MTUs of the links along the tunnel or the
link-layer hops along the path of the link protocol, minus the
tunnel/link encapsulation overhead
2. - the reassembly size of the tunnel/link egress, minus the
tunnel/link encapsulation overhead
Note that (1) would never be larger than (2), so (2) is sufficient for
both a tunnel and a link protocol.
An IP path MTU is determined only by (1).
This is one way in which a tunnel is more like a link than an IP path.
One other way is that an IP packet hopcount/ttl is never decremented
when traversing a link or a tunnel *because* it does not encounter an IP
router along the way, and only IP routers perform this decrement, i.e.,
an IP packet with TTL=0 should be able to traverse both a link and a
tunnel, but would not traverse an IP path.
> - the fragmented segments may be out of order when arriving
> at the egress node of the tunnel, whereas over a link, the fragmented
> frames always arrive at egress port in the same order (therefore the
> reassembly is much easier over a link).
>
A link is not guaranteed to avoid reordering or loss. A particular link
protocol may have one or both of these properties, but it is not a
requirement to be a link.
>
>
> Another question, in Section 5.2: why you specifically discuss the
> “egress MTU” ?
>
See above.
> A tunnel MTU is determined by the minimum MTU of all the links’ MTU
> that the tunnel traverse.
>
This is incorrect, as noted above (and described in the document). The
egress MTU determines the largest IP packet (or fragment) that can
traverse either a link or a tunnel.
> The HSrc and HDst would have considered all the links’ MTU when they
> choose the frame size. So the tunnel egress MTU would be big enough
> for the original packet size between HSrc & HDst.
>
Consider a link such as ATM: the ATM cell size is not relevant, only the
ATM AAL5 reassembly payload size. That determines the MTU because an IP
packet that large can traverse an ATM link (with multiple ATM link hops)
without needing to be fragmented before traversal.
The same is true for an IP tunnel. The hops of the tunnel are not
relevant *to the packet arriving at the ingress*. The only thing that is
relevant is the largest payload the tunnel egress can reassemble. The
hops within the tunnel determine how the ingress fragments, not whether
a packet arriving at the ingress must be dropped.
>
>
> A tunnel MTU is a critical issue, not because of Tunnel being like a
> link”, but
>
> - because the ingress adds the outer header encapsulation
> which may make the total frame size chosen by the original source to
> exceed the MTU of some intermediate links,
>
The overhead of these encapsulations is relevant only at the egress
reassembly; the effect on the individual fragments is not relevant. IP
doesn't care about the 5-byte overheads for ATM cells.
> - because the fragmented segments may be out of order when
> arriving at the egress node of the tunnel, whereas over a link the
> fragmented frames always arrive at egress port in the same order
> (therefore the reassembly is much easier over the link).
>
As noted above, in-order delivery is ensured only for some link
technologies/protocols.
>
>
> A couple of minor typo:
>
>
>
> Section 3.6.1: “the term "inner")..”, is the “)” extra?
>
Yes - thanks for pointing that out. It'll be fixed in the next rev.
>
>
> Section 4.2 first sentence: “…. It messages might be …”, do you mean
> “… its messages might be…”
>
I'll double-check tomorrow, but I'm fairly sure I meant to just drop the
"it" part. Again, it'll be fixed in the next rev.
Joe
>
>
> Linda
>
>
>
>
>
> *From:*Joe Touch [mailto:[email protected]]
> *Sent:* Thursday, October 06, 2016 4:10 PM
> *To:* Linda Dunbar <[email protected]>; [email protected]
> *Cc:* [email protected]
> *Subject:* Re: Questions to draft-intarea-tunnels-03
>
>
>
> Hi, Linda,
>
>
>
> On 10/6/2016 1:34 PM, Linda Dunbar wrote:
>
> Joe and Mark,
>
>
>
>
>
> You said “Because tunnels are links, they are subject to the same
> issues as any link, e.g. MTU..”
>
> The MTU issue exist between any two points in a network.
>
>
> A link MTU is different from a path MTU, as explained in the document.
> The MTU issues of a link are different than those of a path, as described.
>
>
>
> The MTU issue for tunnel is more like the MTU issue between any
> two points in the network (i.e. traverse many links, and can
> change over time), less like the MTU for a single link because the
> single link MTU is only determined by the fixed TWO endpoints of
> the link, whereas the MTU of a tunnel (and a path) is impacted by
> many links in between, i.e. more dynamic and can change depending
> which path the packet traverse through.
>
>
> Both a link and tunnel may have multiple hops not visible to IP, each
> of which may have a different MTU; this is no different than an IP
> path MTU. The difference is that the link/tunnel hops are not visible
> to IP.
>
>
>
>
> In the section 1 of your draft, you stated: “.. tunnels emulate a
> link”. To me, “tunnel” hide the inner addresses, but the packets
> can traverse many links. So Tunnels hardly emulate a link.
>
>
> There are many link layer technologies which use multiple link-layer
> hops and relaying, including Ethernet, ATM, SONET, etc.
>
> Joe
>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
