HI, Fred,
On 5/3/2017 1:07 PM, Templin, Fred L wrote:
> Hi Joe,
>
>> -----Original Message-----
>> From: Joe Touch [mailto:to...@isi.edu]
>> Sent: Wednesday, May 03, 2017 11:47 AM
>> To: Templin, Fred L <fred.l.temp...@boeing.com>
>> Cc: int-area@ietf.org
>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
>>
>> Hi, Fred,
>>
>> Your response keeps raising the same issues that I think we agree upon:
>>
>> - PMTUD always has the possibility of creating black holes (whether
>> in the presence of multipath or not)
>>
>> - PLPMTUD can generate cases where the MIN isn't actually detected
>>
>> and some claims with which I disagree:
>>
>> - that PMPMTUD probes travel different paths than the data
> I think I have already said this many times, but let me try again. The
> tunnel ingress is not the source of the transit packet; it is only the
> source of the tunnel packet. And, the ingress may have to tunnel
> a wide variety of transit packets sourced by many original sources.
> So, if ECMP somewhere within the tunnel peeks at the transit
> packet, then the packet could take a very different path within
> the tunnel than the ingress' PLPMTUD probes took.
OK, so we have to separate things out.
PLPMTUD E2E will still work fine - or not - and isn't affected by the
presence of a tunnel per se.
The same is true for PMTUD E2E.
The issue is how the tunnel itself figures out MTU values larger than
the required minimums for transit to the egress. There are two cases:
- for egress reassembly, a tunnel protocol can communicate that
reassembly MTU explicitly (and the MIN taken for multipoint tunnels, as
with multicast)
- for transit between ingress and egress, the tunnel would need to
either use PMTUD (and be susceptible to black holes) or PLPMTUD
- if it uses PLPMTUD, then steps need to be taken to either
establish the ingress-egress as a single flow (so that ECMP would treat
it as such) or to somehow try to manage subsets of arriving flows as a
single flow
and any such method needs to be careful to ensure that the
probe packets are not distinguishable from non-probes, or could create
false information
Would that be sufficient?
...
>
>> Those probes should be used to determine an MTU only for a
>> given flow; the potential hazards of sharing that information across
>> flows is already discussed in that RFC.
> I don't think RFC4821 does enough to take ECMP into account when it
> talks about storing and sharing discovered MTUs.
While I agree, this document is not intended to update that nor to
account for its deficiencies, so I'm not sure what to add other than as
stated above.
...
>
>> I don't yet see any explanation as to why this would be true.
>>
>> So I'm left with the following, which I propose as the way forward:
>>
>> - the text will be clear about the potential issues for multipath
>> potentially taking a long time to converge
> It's not that it could take a long time to converge - it is that it might
> never converge if some paths of the multipath block ICMPs.
If the path can't differentiate data and probes (see above), I can't see
how they can be prevented from converging.
...
> ...
> The tunnel ingress is only the source of the tunnel packets; it is not the
> source of the transit packets. The only way for PLPMTUD to function
> properly in the presence of ECMP would be for the source of the transit
> packets to do the RFC4821 probing - not the tunnel ingress.
Agreed - the only reason the ingress would want to do PLPMTUD probing is
to increase the size of the chunks sent to the egress.
Joe
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
