Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Thursday, April 23, 2015 10:51 AM > To: Templin, Fred L; Ronald Bonica; [email protected] > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > On 4/23/2015 10:39 AM, Templin, Fred L wrote: > ... > >>>> I repeat: Probe success tells you only that. Probe loss tells you only > >>>> that. > ... > >> If the probe makes it, it makes it. > >> > >> If the probe "would have failed" on another path, you'll either see that > >> over several probes or not. > > > > Only if you craft your probes in such a way that they eventually test > > all paths in a multipath arrangement. > > I need to do no such thing. > > I only care about what happens as it happens. If the path changes and it > affects loss, then I react to loss. If the path doesn't change and the > loss changes, I react to loss. > > There's nothing that requires that any network path "test all paths" in > a multipath system.
You are missing the point. With ECMP or LAG, a middlebox in the path from the ingress to the egress selects a path for the tunneled packet by examining information in the headers such as the flow label. If all tunneled packets look the same to the middlebox (i.e., the pipe model) then they will all take the same path and it becomes conceivable to test the (uni-path) MTU through probing. But, if tunneled packets are crafted to reflect the flow information in the data packets they are carrying, then, the middlebox can send different tunneled packets across different paths unbeknownst to the tunnel ingress. Let's say that there are 2^20 paths in the multipath (i.e., one for each flow label) - how can the tunnel test the MTU of all paths? > ,,, > >> If you do, you have what is isomorphic to a > >> lossy link, > > > > It would actually be much worse than a lossy link, because some > > traffic would receive good service while other traffic would be > > dropped completely. > > If the loss starts depending on the contents of the packets, then we'd > need a new mechanism to provide feedback on existing packets as if they > were all probes. The data packets themselves as probes is the only way to test the paths that the data packets take. The probe reply is a Packet Too Big message. But, if you get a PTB for a data packet that is smaller than 1280 you are back to fragmentation. > That's clearly out of scope for this doc. > > Although I agree that fragmentation should be used *if available* to > avoid this issue, we're clearly talking about when that's not the case > either because of hardware or protocol limitations. Huh? Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
