Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

[Manoj Nayak <[e-mail]>]

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.


  1.  Destination is outside tunnel.
  2.  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


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 <[e-mail]>
Date: Friday, 15 November 2019 at 8:20 PM
To: Manoj Nayak <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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