Hello Bob,
Please find my reply.
>>Naming the draft "Lossless Path MTU Discovery (PMTUD)? seems to be very
>>aspirational, and is an oxymoron.
>>ICMP message can be rate limited and dropped in the network. Hardly ?
>>lossless?.
>>A different title might be better.
I think that when we say lossless , we refer to a PMTU without blackhole. In
our approach, black holing is
prevented as sender gets an ack for it’s sent packet even when ICMP messages
are dropped.
A PMTU black hole is where the ICMP message doesn't reach the sending host to
inform it that it needs to adjust
its MTU. This can be down to the router not sending the ICMP message or the
ICMP message being blocked
on the way back to the sender, In this scenario the sender is waiting for an
acknowledgment for its sent packet.
The destination is still waiting for its packet, and the whole session falls
down.
>>The document says:
>> This document describes alternative PMTUD procedures that do no rely
>> on the network's ability to deliver ICMP Destination Unreachable
>> messages to the source node.
>>This is not really correct, your are still dependent on the networks ability
>>to deliver
>>ICMP messages to the source node. Just not ICMP Destination Unreachable
>>messages.
>> A new ICMP message isn?t going to be better, perhaps worse.
Yes, we are dependent on networks ability to deliver ICMP messages to source
node
to get actual MTU size at source node. But without actual MTU size at source
node,
source node continue to operate normal way by sending further packets to
destination
and intermediate node continues to fragment packets.
>>I didn?t understand the purpose of the Code field, that can indicate
>>reassembly error.
>>What is the purpose of this? This seems to be in conflict with this message
>>that
>>is sent when the destination node successfully reassemblies a set of
>>fragments.
>>With the code indicating reassembly error, it is saying that the fragments
>>were not reassembled.
When destination node successfully reassemblies a set of fragments for a bunch
of packets,
the destination node sends ack to sender. However our idea does not compare the
ack with a ICMP message
with reassembly error. Because ack is sent for one packet or multiple packets
and ICMP message
with reassembly error is sent for each packet. So we can not co-relate these
two.
With the code indicating reassembly error, fragment size mentioned in ICMP
message is not
considered by source for PMTU.
Hope it clarifies.
Regards
Manoj Nayak
------------------------------
Message: 3
Date: Thu, 31 Oct 2019 16:51:10 -0700
From: Bob Hinden <[email protected]>
To: Ron Bonica <[email protected]>
Cc: Bob Hinden <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [Int-area] New Version Notification for
draft-bonica-intarea-lossless-pmtud-01.txt
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Ron,
A few comments on your draft.
Naming the draft "Lossless Path MTU Discovery (PMTUD)? seems to be very
aspirational, and is an oxymoron. ICMP message can be rate limited and dropped
in the network. Hardly ?lossless?. A different title might be better.
I do like the idea of the destination sending feedback, we have worked on
some other drafts with that property.
The document says:
This document describes alternative PMTUD procedures that do no rely
on the network's ability to deliver ICMP Destination Unreachable
messages to the source node. In these procedures, the source node
produces an initial PMTU estimate. This initial estimate is equal to
the MTU of the first link along the path to the destination node. It
can be greater than the actual PMTU.
This is not really correct, your are still dependent on the networks
ability to deliver ICMP messages to the source node. Just not ICMP Destination
Unreachable messages. A new ICMP message isn?t going to be better, perhaps
worse.
I didn?t understand the purpose of the Code field, that can indicate
reassembly error. What is the purpose of this? This seems to be in conflict
with this message that is sent when the destination node successfully
reassemblies a set of fragments. With the code indicating reassembly error, it
is saying that the fragments were not reassembled.
It may be folly to try to modify IPv4 implementations at this point. I
have no objections if you wish to try pushing this big rock up hill, but I
doubt you will be successful.
I see you have several co-authors from Harvey Mudd College.
Bob
> On Oct 31, 2019, at 12:16 PM, Ron Bonica
<[email protected]> wrote:
>
>
> Updated draft
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Thursday, October 31, 2019 3:15 PM
> To: Ron Bonica <[email protected]>; Hakan Alpan <[email protected]>; Radon
Rosborough <[email protected]>; Bradely Newton <[email protected]>; Bradley
Newton <[email protected]>; Miles President <[email protected]>; Manoj Nayak
<[email protected]>
> Subject: New Version Notification for
draft-bonica-intarea-lossless-pmtud-01.txt
>
>
> A new version of I-D, draft-bonica-intarea-lossless-pmtud-01.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
repository.
>
> Name: draft-bonica-intarea-lossless-pmtud
> Revision: 01
> Title: Lossless Path MTU Discovery (PMTUD)
> Document date: 2019-10-31
> Group: Individual Submission
> Pages: 7
> URL
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-01__;!8WoA6RjC81c!XLNEZ-1XcW1SCcQkdY1e72UP_43UD2slIH4JB_BJ-gO_XISUMzEDSldcRkqU5JMOvqw$
> 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!XLNEZ-1XcW1SCcQkdY1e72UP_43UD2slIH4JB_BJ-gO_XISUMzEDSldcRkqUNjQlVhU$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL:
<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/int-area/attachments/20191031/999da00d/attachment.asc__;!8WoA6RjC81c!XLNEZ-1XcW1SCcQkdY1e72UP_43UD2slIH4JB_BJ-gO_XISUMzEDSldcRkqUrBUvJx8$
>
------------------------------
Subject: Digest Footer
_______________________________________________
Int-area mailing list
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!XLNEZ-1XcW1SCcQkdY1e72UP_43UD2slIH4JB_BJ-gO_XISUMzEDSldcRkqUNjQlVhU$
------------------------------
End of Int-area Digest, Vol 170, Issue 14
*****************************************
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
