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

[Joe Touch <[e-mail]>]

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