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. 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.
>>- 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. In our implementation,
We can assume the first fragment to be largest fragment. This first fragment
remains
Largest fragment unless until one more fragment is found to be greater than the
first fragment.
For example:
While assembling the fragments,
I=0;
Largest Fragment = packet-I;
For (, I < n , ++I)
If ( packet-I > Largest Fragment)
Largest Fragment = packet-I;
Hopefully I did not miss anything.
Regards
Manoj Nayak
------------------------------
Message: 3
Date: Tue, 29 Oct 2019 21:43:33 -0700
From: Joe Touch <[email protected]>
To: Ron Bonica <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [Int-area] New Version Notification for
draft-bonica-intarea-lossless-pmtud-00.txt
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi, Ron,
A few things come to mind. The first one, IMO, renders the rest somewhat
less important.
Joe
-------------
- this approach applies only to IPv4; not sure it?s worth trying to
optimize for only that case
(it requires on-path fragmentation permitted)
- this approach relies on ICMPs, so it?s as robust (or, more to the point,
not) as PMTUD
if ICMPs can find the reverse path from the dest, why wouldn?t the
routers?
i.e., isn?t the problem with ICMPs not just routers not sending them
but firewalls BLOCKING them?
(i.e., if ICMPs would work here, PMTU would have worked, rendering this
unnecessary)
- 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)
- 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
> On Oct 29, 2019, at 9:53 AM, Ron Bonica
<[email protected]> wrote:
>
> Folks,
>
> Please review and comment.
>
> Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Tuesday, October 29, 2019 11:48 AM
> To: Ron Bonica <[email protected]>; Hakan Alpan <[email protected]>; Radon
Rosborough <[email protected]>; Bradely Newton <[email protected]>; Miles
President <[email protected]>; Manoj Nayak <[email protected]>
> Subject: New Version Notification for
draft-bonica-intarea-lossless-pmtud-00.txt
>
>
> A new version of I-D, draft-bonica-intarea-lossless-pmtud-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
repository.
>
> Name: draft-bonica-intarea-lossless-pmtud
> Revision: 00
> Title: Lossless Path MTU Discovery (PMTUD)
> Document date: 2019-10-29
> Group: Individual Submission
> Pages: 8
> URL:
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-00__;!8WoA6RjC81c!XifH7EcqHRKXHyGSwB3ojXm6YmKn_vYWCjgM-VDTPTEzP-khJGlb9MqM8x-YTELKJ64$
>
>
>
> Abstract:
> This document describes alternative IPv4 PMTUD procedures that do not
> prevent IP fragmentation and do no rely on the network's ability to
> deliver ICMP Destination Unreachable messages to the source node.
> This document also defines a new ICMP message. IPv4 nodes emit this
> new message when they reassemble a fragmented packet.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
> _______________________________________________
> Int-area mailing list
> [email protected]
>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!XifH7EcqHRKXHyGSwB3ojXm6YmKn_vYWCjgM-VDTPTEzP-khJGlb9MqM8x-YOVqXLNE$
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
