You haven’t answered any of the questions I asked, including the one about tunnels.
The point about tunnels is that the numbers you’re assuming don’t account for the space needed for tunneling. The portion of RFC2003 below acts like a router; it isn’t relevant to your mechanism. Sec 5.2 of draft-ietf-intarea-tunnels also points out several errors in that RFC, including those in how that RFC refers to and calculates MTUs. Joe > On Nov 23, 2019, at 6:23 AM, Manoj Nayak <[email protected]> wrote: > > Hello Joe, > > Section 5 of the below RFC talks about the way to relay MTU size to sender if > ipv4-to-ipv4 tunnel is > there in the path from sender to destination. > > There are two cases here. > > Destination is outside tunnel. > Destination is tunnel end point. > > When destination is tunnel end point then MTU size is returned to sender > using soft state maintained > at tunnel entry point. > > https://tools.ietf.org/html/rfc2003 <https://tools.ietf.org/html/rfc2003> > > <> > 5 <https://tools.ietf.org/html/rfc2003#section-5>. Tunnel Management > > > Unfortunately, ICMP only requires IP routers to return 8 octets (64 > bits) of the datagram beyond the IP header. This is not enough to > include a copy of the encapsulated (inner) IP header, so it is not > always possible for the encapsulator to relay the ICMP message from > the interior of a tunnel back to the original sender. However, by > carefully maintaining "soft state" about tunnels into which it sends, > the encapsulator can return accurate ICMP messages to the original > sender in most cases. The encapsulator SHOULD maintain at least the > following soft state information about each tunnel: > > - MTU of the tunnel (Section 5.1 > <https://tools.ietf.org/html/rfc2003#section-5.1>) > - TTL (path length) of the tunnel > - Reachability of the end of the tunnel > > > Regards > Manoj Nayak > > From: Joe Touch <[email protected] <mailto:[email protected]>> > Date: Friday, 15 November 2019 at 8:20 PM > To: Manoj Nayak <[email protected] <mailto:[email protected]>> > Cc: "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > Subject: Re: [Int-area] New Version Notification for > draft-bonica-intarea-lossless-pmtud-00.txt > > > > >> On Nov 13, 2019, at 8:34 PM, Manoj Nayak <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hello Joe, >> >> Please find my reply. >> >> >>>> - why does this doc assume the max ICMP is 576? >>>> we?re still talking IPv4 here; it?s still 68 (that?s why only 64 bits >>>> of the orig payload are guaranteed) >>>> (yes, your note in the end of sec 1 is relevant, but given v4-in-v4 >>>> tunneling, it?s possible that >>>> paths might be smaller than the 576 assumption) >> >> We use an unused field in first 8 bytes of ICMP error/reply message. > > Please explain. Most ICMP messages have 4 bytes of unused field, but not all > (one has only 3). > > >> How the idea would be >> affected if minimum packet size is 68 bytes or 576 bytes. As per my >> understanding, >> existing ICMP error/reply message works in v4-in-v4 tunnelling, so it would >> continue to >> work with the idea proposed in our draft. we won’t let the ICMP message >> exceed a reasonable size. >> in our implementation, that will be 576. > > Sending the largest response possible given an untunneled MTU size is an > invitation to black-hole the response itself if (when) an IPv4-in-IPv4 tunnel > is encountered. > > In most situations, ICMP responses are received from small initial messages > that don’t stress that limit. The use in this doc is the opposite - it relies > on ongoing use of ICMP for max-sized packets and returns max-sized payloads. > This isn’t helpful. It would be more useful to try to limit the size to the > minimum expected to be useful and account for these other encapsulations. > > >> >> >>>> - why would this approach find the largest fragment through a system? >>>> rfc1812 talks about various strategies, one of which is ?equal >>>> sized?, which might never find >>>> the max the way you propose >> >> >> As per section 4.2.2.7 from rfc 1812, >> >> “There are several fragmentation techniques in common use in the >> Internet. One involves splitting the IP datagram into IP >> fragments with the first being MTU sized, and the others being >> approximately the same size, smaller than the MTU. “ >> >> In both of the above cases, idea in our draft works. > > The issue is further down in that section: > > One other fragmentation technique discussed was splitting the IP > datagram into approximately equal sized IP fragments, with the > size less than or equal to the next hop network's MTU. ... > > In that case, none of the fragments gives you the path MTU. > > Joe
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
