Subject: Fwd: Re: DISCUSS's on rfc1981bis - MK Comments

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 09 May 2017 13:07:10 +0100

Thanks for the comments. I helped Bob with some of the new text and so have some comments.
See below, my comments are marked "GF". I think we can prepare a new rev. to address most of these.

Gorry

-------- Original Message --------

>  On May 9, 2017, at 12:24 PM, Gorry Fairhurst<[email-masked]>  wrote:
>
>  On 09/05/2017, 09:35, Bob Hinden wrote:
>>  Joe, Gorry,
>>
>>  There are some new discusses on rfc1981bis.  See:
>>
>>  https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ballot/
>>
>>  I think the one from Alvaro is resolved.
>>
>>  I would like your input on the one from Mirja.  There are also comments from ekr and Warren.
>>
>>  Thanks,
>>  Bob
>>
>>
>
>  I know this is a bis document and my discuss does not address any text that changed in the bis version but given all previous discussion, I would like to discuss the following text parts on statements regarding retransmissions which don't seem to be appropriate for this document and are partly even wrong.
>  In general it does not make a lot of sense to talk about retransmission semantics in this document because this really depends on the upper layer protocol, and I'm really not sure if any implementaiton of a reliable transport does send retransmission based on the receptions of PTB messages (if exposed) rather than only relying on it's own loss detection mechanism. This discuss concerns a few sentence all over the document and most parts of section 5.4. Details proposals below:
>
GF: We already removed most of this, and we can remove more.
>
>  I propose to either remove this sentence, or at least reword to the following (or something similar):
>  OLD:
>  "Retransmission should be done for only for those packets that are
>  known to be dropped, as indicated by a Packet Too Big message."
>  NEW:
>  "The IP layer may indicate loss to the upper layer protocol of those packets that are
>  known to be dropped, as indicated by a Packet Too Big message."
>  Or MAY or SHOULD or MUST...?
>
GF: I'd prefer to remove, rather than replace. This new text isn't helping me.
>  ----
>  Subsequently the following sentence should be removed as well:
>  "An upper layer must not retransmit data in response to an increase in
>  the PMTU estimate, since this increase never comes in response to an
>  indication of a dropped packet."
>
GF: I have no problems with this sentence being in the document, but I
do not think this is important, and deleting this is also fine with me.
>  ----
>  And here is the bigger change in section 5.4:
>  OLD
>  "When a Packet Too Big message is received, it implies that a packet
>  was dropped by the node that sent the ICMPv6 message. It is
>  sufficient to treat this in the same way as any other dropped
>  segment, and will be recovered by normal retransmission methods. If
>  the Path MTU Discovery process requires several steps to find the
>  PMTU of the full path, this could delay the connection by many round-
>  trip times.
>
>  Alternatively, the retransmission could be done in immediate response
>  to a notification that the Path MTU has changed, but only for the
>  specific connection specified by the Packet Too Big message. The
>  packet size used in the retransmission should be no larger than the
>  new PMTU."
>  NEW
>  "When a Packet Too Big message is received, it implies that a packet
>  was dropped by the node that sent the ICMPv6 message. A reliable
>  upper layer protocol will detect the loss of this segment, and recover
>  it by its normal retransmission methods. Depending on the loss
>  detection method that is used by the upper layer protocol, this
>  could delay the connection by many round-trip times.
>
>  Alternatively, the retransmission could be done in immediate response
>  to a notification that the Path MTU was decreased, but only for the
>  specific connection specified by the Packet Too Big message. The
>  packet size used in the retransmission should be no larger than the
>  new PMTU."
>
GF: I have no problem with the new text, but I regret that this does
not also include this - which I think is helpful context:
  "If
  the Path MTU Discovery process requires several steps to find the
  PMTU of the full path, this could delay the connection by many round-
  trip times."
>  ----
>  I don't understand the following paragraph. Can this be removed?
>  "Note: A packetization layer must not retransmit in response to
>  every Packet Too Big message, since a burst of several oversized
>  segments will give rise to several such messages and hence several
>  retransmissions of the same data. If the new estimated PMTU is
>  still wrong, the process repeats, and there is an exponential
>  growth in the number of superfluous segments sent."
>
GF: I think the example is important. I'm not sure why that would be removed.
>  ----
>
>  The following text is fine but probably is not needed if the whole document is reworded accordingly to ensure that retransmissions are solely the responsibility of the upper layer protocol:
>  "Retransmissions can increase network load in response to
>  congestion, worsening that congestion. Any packetization layer
>  that uses retransmission is responsible for congestion control of
>  its retransmissions. See [RFC8085] for more information."
>
GF: I'd prefer not to remove, it can't be assumed that all protocols doing PMTUD are TCP-like.
>  ---
>  This can also be removed, because a reliable protocol that detected loss and decided to send a retransmission, should and will do the same processing as for all other retransmissions, e.g. reset the retransmission time in TCP. Mentioning this separately is rather confusing.
>  "This means that the TCP layer must be able to recognize when a
>  Packet Too Big notification actually decreases the PMTU that it
>  has already used to send a packet on the given connection, and
>  should ignore any other notifications."
>
GF: Removing that would be fine with me (I think it's assumed, and so we do not need to say).
>  ----
>  And this is even incorrect. Slow start means that you will increase the connection window exponentially. Only sending one segment means setting the congestion/sending window to one. I propose the following change:
>  OLD
>  "Many TCP implementations incorporate "congestion avoidance" and
>  "slow-start" algorithms to improve performance [CONG]. Unlike a
>  retransmission caused by a TCP retransmission timeout, a
>  retransmission caused by a Packet Too Big message should not change
>  the congestion window. It should, however, trigger the slow-start
>  mechanism (i.e., only one segment should be retransmitted until
>  acknowledgements begin to arrive again)."
>  NEW
>  "A loss caused by a PMTU probe indicated by the reception of a Packet Too Big message MUST NOT be considered as a congestion notification and hence the congestion window may not change."
>
GF: That would prune the text further, I'd be really happy with this replacement.
>  ---
>
>  And I also don't understand this sentence:
>  "TCP performance can be reduced if the sender's maximum window size is
>  not an exact multiple of the segment size in use (this is not the
>  congestion window size)."
>
GF: I think this should be removed, the sentence is implementation-specific and not important here.
>
>  ---
>
>  Comment (2017-05-08)
>  1) I agree with Ekr on this sentence:
>  "Nodes SHOULD appropriately validate the payload of ICMPv6 PTB
>  messages to ensure these are received in response to transmitted
>  traffic (i.e., a reported error condition that corresponds to an IPv6
>  packet actually sent by the application) per [ICMPv6]."
>  This sounds like it should be a MUST but I guess it depends on the upper layer protocol if such a validation is possible or not, e.g. if information are available that can be used for validation. Maybe you can be more explicit here and even say something like pmtu discovery should/must only be used if the upper layer protocol provides means for validation of the icmp payload (like a sequence number in TCP)…?
>
GF: I think this cannot be a MUST - because there are many cases in which full validation is not possible.
Mirja's comment assumes that the packet header is visible in the ICMPv6 payload
and the endpoint can find this and verify it. if necessary, this needs to explain corner
cases where this is not possible. Placing a MUST requirement is a significnat change.
Requiring a reliable transport is also a large change - it may be that the risk of
bogus PTB messages can be mitigated in some other way.
I prefer the current text - but willing to look at more text instead. See comment by Suresh.
>
>  ---
>  Further also note that if the upper layer does the validation while the IP layer maintains EMTU_S, there must be an interface from the upper layer to the IP layer to tell if a packet is valid or not before the IP layer updates the MTU estimate. This seems actually more complicated than this one sentences indicates.
>
GF: The need for an "interface" is implementation dependent, I'd prefer to avoid discussing how/where this is implemented.
>
>  ---
>
>  2) Also as Ekr says, I also have problems to fully understand this normative text in section 4:
>  "After receiving a Packet Too Big message, a node MUST attempt to
>  avoid eliciting more such messages in the near future. The node MUST
>  reduce the size of the packets it is sending along the path. Using a
>  PMTU estimate larger than the IPv6 minimum link MTU may continue to
>  elicit Packet Too Big messages. Since each of these messages (and
>  the dropped packets they respond to) consume network resources, the
>  node MUST force the Path MTU Discovery process to end.
>
>  Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast
>  as possible."
>  I especially don't understand the first part, given that a PTB message may still indicate a MTU that is larger than the minimum link MTU which then may cause another PTB message later on the path. This text reads like if you receive one PTB message you should better end discovery and fall back to the minimum link MTU to avoid any further PTB message and not waist any resources. I don't think that's the intention and as such I don't understand when it is recommended to end discovery here...?
>
GF: The text seems good to me. I don't understand the comment from Mirja.
  I wonder if this is in the eyes of the reader, and some rewording would help?
  (I suggest the last two sentences could be combined:
  "Since each of these messages (and
  the dropped packets they respond to) consume network resources,
  Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast
  as possible.""
>
>  ---
>  3) Section 5.2 seems to be written with only single homed hosts in mind. It might be good to advise that the pmtu information should always be stored on a per interface basis...?
>

GF: Agree: Path MTU information should be maintained for each Ipv6 interface. This should be clear.
>
>  ---
>  4) Also section 5.2:
>  You only advise to store information per flow ID, however, if the flow label is not used, wouldn't it make really sense to just use the 5-tuple instead? Also note that EMCP is often done based on the 5-tuple or even 6-tuple (with the ToS field).
>
GF: The TOS field doesn't exist for IPv6 (nor for IPv4 any more).
I really don't think we should be considering DSCP as an index for path information.

GF: I thought the text reads about "path", it's intentionally not precise.
>
>  ---
>  5) And more in section 5.2:
>  "When a Packet Too Big message is received, the node determines which
>  path the message applies to based on the contents of the Packet Too
>  Big message. "
>  MAYBE:
>  "When a valid Packet Too Big message is received, the node determines which
>  path the message applies to based on the contents of the Packet Too
>  Big message."
>
GF: That would be OK, but I guess, the way it knows it is valid is because it finds
a valid path - so not sure the change makes this clearer.
>
>  ---
>
>  And further on:
>  "If the tentative PMTU is less than the existing PMTU estimate, the
>  tentative PMTU replaces the existing PMTU as the PMTU value for the
>  path."
>  This doesn't cover the case where a pmtu probe with a larger size was send and the PTB message returns a larger value then stored. Maybe state this explicitly.
>
GF: This is wrong. We could explicitly say this is **NOT** allowed.
>
>  ----
>  This applies similar to this sentence in section 6:
>  OLD
>  "A node, however, should never raise its estimate of the
>  PMTU based on a Packet Too Big message, so should not be
>  vulnerable to this attack.“
>  NEW
>  "A node, however, MUST NOT raise its estimate of the
>  PMTU based on a Packet Too Big message that is not a (validated) response to a PMTU probe that was previously send by this node, so should not be
>  vulnerable to this attack."
>
GF: This is wrong. The proposed new text is incorrect.
The old text was correct in sentimemt, but could be stronger:
  "A node, however, must not raise its estimate of the
   PMTU based on a received Packet Too Big message, so it is not be
  vulnerable to this attack.“
>  ----
>  6) Further section 5.2:
>  Should this statement be maybe upper case MUST:
>  "The packetization layers must be notified about decreases in the PMTU."
>
GF: If upper case makes a difference, this is true.
>
>  ---
>  7) Technical comment on section 5.3 in general:
>  There is a difference between aging if a flow is active or not. While I maybe don't want to probe again for this connection because my application already decided to use a mode where it can live with the current pmtu and it's too much effect to switch, I really want to probe at the beginning of the next connection again to check if I can use a different mode now. While the IP layer does not have a notion of connection it can observe if packets are frequently send with the same 5-tuple and reset the cached pmtu after a certain idle time.
>
GF: There are many ways to do this, agreed. Is extra text really needed?
>
>  ---
>  8) Section 5.4: should this maybe be normative, at least the last MUST NOT (be fragmented):
>  "A packetization layer (e.g., TCP) must track the PMTU for the path(s)
>  in use by a connection; it should not send segments that would result
>  in packets larger than the PMTU, except to probe during PMTU
>  discovery (this probe packet must not be fragmented to the PMTU). "
>
GF: If upper case makes a difference, this is true - and probably worth highlighting.
>
>  ----
>
>  Nit:
>  The abbreviation PTB is only used once in section 4 (and never expanded).
>
GF: Should be fixed.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 19 May 2017 10:51:01 -0400

Hi Gorry, hi all,

thanks for the work and the update. All comments from Gorry seemed fine to me and I will try to review the changes in the updated doc soon. One more minor comment on this:

> Am 09.05.2017 um 08:07 schrieb Gorry Fairhurst <[email-masked]>:
> 

The problem is I don’t understand this example. Is there an assumption that all mtu probe packets have been ‚generated‘ on the same packet? If so that makes sense but must the spelled out somewhere!

Mirja

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 20 May 2017 16:11:16 +0100

On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
>> Am 09.05.2017 um 08:07 schrieb Gorry Fairhurst<[email-masked]>:
>>
I think the wording is maybe jumbled, but the point is OK. Perhaps 
something like this would be clearer?

"Note: A packetization layer ought to avoid retransmitting the data in a probe packet
using the size reported in the last Packet Too Big message.
This is to avoid an exponential growth in the number of superfluous segments
that would be sent when a path encounters several successive smaller PMTU limits.
(Each new estimated PMTU would result in retransmission of the data in a smaller
packet that may itself fail if it encounters a still smaller PMTU in a device further
along the same path)."

Gorry

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 22 May 2017 11:49:36 +0200

See below.

> Am 20.05.2017 um 17:11 schrieb Gorry Fairhurst <[email-masked]>:
> 
> I think the wording is maybe jumbled, but the point is OK. Perhaps something like this would be clearer?
> 
I still don’t get it. Each time a packet is dropped, you have to retransmit it (if your transport is reliable) because otherwise the other end will not have it. I also still don’t see how there can be an exponential grows. Sorry if I miss something but maybe you can explain again this case using different words…?

Mirja

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 22 May 2017 12:17:39 +0100

On 22/05/2017 10:49, Mirja Kuehlewind (IETF) wrote:
> I still don’t get it. Each time a packet is dropped, you have to
> retransmit it (if your transport is reliable)
> because otherwise the other end will not have it.
 >
Sure. this says nothing about how you find out what segments need to
be retransmit, only about the *SIZE* of the packets you use to perform 
that transmission.
>
 >
> I also still don’t see how there can be an exponential grows.
 >
 >
> Sorry if I miss something but maybe you can explain again this case using different words…?
>
> Mirja
>

Before I try different words, we should make sure the topic is understood.

Suppose we wish to send a probe for 8KB, and suppose the path supports
3 router MTU sizes: a hop with 4KB MTU and then a later hop with 2KB 
MTU, and finally one of just 1400B.

Largest probe size = 8KB

The first probe sends 8KB as the Segment Size
->------------------------------X
Dropped by first router along path.
In example case PTB indicates next hop =  4KB.
Data not reliably sent.

Largest probe size = 4KB

Retransmit 2 packet for same segment of data, each size 4KB
------------->------------------------------X
------------->------------------------------X
Dropped by router later along path.
In example case PTB indicates next hop =  2KB.
Data still not reliably sent.

Largest probe size = 2KB

Retransmit 4 packets for same segment of data.
In example case PTB indicates next hop =  1400B.
Data still not reliably sent.
------------->------------------------------>---X
------------->------------------------------>---X
------------->------------------------------>---X
------------->------------------------------>---X

Largest probe size = 1400B

Data finally transmitted in 6 packets all less than PMTU.
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->

All data delivered. PMTU=1400B is confirmed.

Total sent packets = 13 packets
No of re-transmissions = 7 (6 failed re-transmissions in 3 
re-transmission attempts)

Now let's try a method that heeds the warning in the text and 
re-transmits the probe data using a "safe: MTU:

The first probe sends 8KB as the Segment Size
->------------------------------X

Dropped by first router along path.
In example case PTB indicates next hop =  4KB.
Data not reliably sent.

Largest probe size = 4KB

Sender resends the 8KB segment using a known workable PMTU (in the above 
1500B, if that were cached, or even 1280B.

------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->
------------->------------------------------>-------------->

Total sent packets = 7 packets
No of re-transmissions = 6 (all successful, 1 re-transmission)

And afterwards separately resend a single probe packet to detect a the 
largest PMTU using the 4KB probe.

Obviously, there are many combinations of paths, and not all cases lead
to exponential growth, but all cases lead to multiple probes, and
multiple re-transmissions.

Gorry

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 22 May 2017 16:31:03 +0200

Hi Gorry,

thanks for the example below. Now I understand. My thinking was that you could also just retransmit the first segment in response to the packet too big message with the new indicated packet size and hold the rest of the to-be-retransmitted packet for later when the MTU probing is terminated. However, the point here is actually not about retransmitting. I guess what you actually need to say is that you should only send one MTU probe at a time. So if you want to retransmit all segments at once you need to use the confirmed PMTU that was used before the probing started, right?

Mirja

> Am 22.05.2017 um 13:17 schrieb Gorry Fairhurst <[email-masked]>:
> 
> be retransmit, only about the *SIZE* of the packets you use to perform that transmission.
>> 
> >
> 3 router MTU sizes: a hop with 4KB MTU and then a later hop with 2KB MTU, and finally one of just 1400B.
> 
> Largest probe size = 8KB
> 
> No of re-transmissions = 7 (6 failed re-transmissions in 3 re-transmission attempts)
> 
> Now let's try a method that heeds the warning in the text and re-transmits the probe data using a "safe: MTU:
> 
> Sender resends the 8KB segment using a known workable PMTU (in the above 1500B, if that were cached, or even 1280B.
> 
> And afterwards separately resend a single probe packet to detect a the largest PMTU using the 4KB probe.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 22 May 2017 16:01:05 +0100

> thanks for the example below. Now I understand. My thinking was that you could also just retransmit the first segment in response to the packet too big message with the new indicated packet size an…
OK - I also don't particularly mind if we change the text.

I'd suggest not even retransmitting the probe packet as another probe 
(if this data needs to be sent reliably). If there is more data, that 
later data can be used for the probe, I think there is really no need to 
hurry this procedure be vulnerable to multiple losses and re-transmits.

So, without trying to sketch a definition of a method - which I think is 
outside of the spirit of this update, can we simply identify what is the 
key thing to highlight?

Gorry

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 22 May 2017 17:02:42 +0200

Yes, please propose new text.

> Am 22.05.2017 um 17:01 schrieb Gorry Fairhurst <[email-masked]>:
> 
> I'd suggest not even retransmitting the probe packet as another probe (if this data needs to be sent reliably). If there is more data, that later data can be used for the probe, I think there is really no need to hurry this procedure be vulnerable to multiple losses and re-transmits.
> 
> So, without trying to sketch a definition of a method - which I think is outside of the spirit of this update, can we simply identify what is the key thing to highlight?
> 
> Gorry
> 
>>

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 23 May 2017 08:50:58 +0100

Here is my proposed replacement text, it focusses on retransmission, because other clauses deal with otehr aspects of handling PTB:

"Note: A packetization layer that determines a probe packet is lost, needs to avoid retranmission using a packet size that may induce multiple retransmission. This could occur if it retransmitted the data segmented into packets of the size reported in the last Packet Too Big message and there were several successively smaller PMTU limits at the routers along the path. The resulting sequence of probe packets would require multiple retransmissions (with retransmitted probes also dropped by a router later along the path), with unecessary delay of the data and transmission of superfluous packets that contribute to the network load under congestion. Any packetization layer that uses retransmission is therefore also responsible for congestion contol of its retransmissions [RFC8085]."

Gorry

On 22/05/2017, 16:02, Mirja Kuehlewind (IETF) wrote:
>> Am 22.05.2017 um 17:01 schrieb Gorry Fairhurst<[email-masked]>:
>>
>>>> Am 22.05.2017 um 13:17 schrieb Gorry Fairhurst<[email-masked]>:
>>>>
>>>>>> Am 20.05.2017 um 17:11 schrieb Gorry Fairhurst<[email-masked]>:
>>>>>>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 23 May 2017 13:20:35 +0200

Hi Gorry,

my thinking was that the IP layer should actually not indicate a new PMTU until the probing is completed and as such only probing packets should have a larger size than indicated by the current PMTU. However, I actually don’t know how this is implemented in reality.

I think the text below from you is better but now that I understand what it wants to say, I can understand it but I'm still not sure if it’s otherwise clear. Let me give a try:

"A packetization layer that determines a probe packet is lost, needs to adapt the segment size of the retransmission. Using the reported size in the last Packet Too Big message, however, can lead to further losses as there might be smaller PMTU limits at the routers further along the path. This would lead to loss of all retransmitted segments and therefore cause unnecessary congestion and amplification each time a new router announces a smaller MTU. The packetization layer therefore should not send any packets with a new PMTU that do not belong to the probing itself until the probing is completed and at least one packet with the new PMTU was successfully received at the other end. During the probing phase the packetization layer should either continue to use the previous PMTU or the minimum PMTU for all packet that are not probe packets, including retransmissions.“

I guess we could even use SHOULD and SHOULD NOT…?

What do you think?

Mirja

> Am 23.05.2017 um 09:50 schrieb Gorry Fairhurst <[email-masked]>:
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 23 May 2017 14:34:12 +0100

See below...

This starts good:

 >"A packetization layer that determines a probe packet is lost,
 >needs to adapt the segment size of the retransmission.
 >Using the reported size in the last Packet Too Big message,
 >however, can lead to further losses as there might be smaller
 >PMTU limits at the routers further along the path.
 >This would lead to loss of all retransmitted segments
 >and therefore cause unnecessary congestion and amplification each time
 > a new router announces a smaller MTU.

- Up to here, I agree, amplification may not be completely clear to a 
reader, could we say something like additional packets (or something?)

Then, the text now starts to prescribe how to do this:

 > The packetization layer therefore should not send any packets
 > with a new PMTU that do not belong to the probing itself
 > until the probing is completed and at least one packet with
 > the new PMTU was successfully received at the other end.

- This sounds rather like an algorithm, possibly
one that is based PLMTUD, and I'd rather not venture into how this is 
implemented.

 > During the probing phase the packetization layer should
 > either continue to use the previous PMTU or the minimum
 > PMTU for all packets that are not probe packets,
 > including retransmissions.“

- I don't really have a concept of a "probing phase"...
and "previous PMTU" is slightly problematic, in that the
cause of the PTB message may have been a path MTU reduction.
My concern is that this starts to explain a new algorithm.

I think it's still worth citing RFC8085, since it's
predominately UDP Apps that need to roll their own
PMTU discovery.

Gorry

>> Here is my proposed replacement text, it focusses on retransmission, because other clauses deal with other aspects of handling PTB:
>>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 24 May 2017 08:48:44 -0700

Hi,

> On May 23, 2017, at 6:34 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> See below...
> 
> - Up to here, I agree, amplification may not be completely clear to a reader, could we say something like additional packets (or something?)

How about:

A packetization layer that determines a probe packet is lost,
needs to adapt the segment size of the retransmission.
Using the reported size in the last Packet Too Big message,
however, can lead to further losses as there might be smaller
PMTU limits at the routers further along the path.
This would lead to loss of all retransmitted segments
and therefore cause unnecessary congestion as well as additional
packets to be sent each time a new router announces a smaller MTU.

> one that is based PLMTUD, and I'd rather not venture into how this is implemented.
> 

So we could add (this was in an earlier version):

      Any packetization layer that uses
      retransmission is therefore also responsible for congestion
      control of its retransmissions [RFC8085].

The resulting text in Section 5.4, would be:

      Note: A packetization layer that determines a probe packet is
      lost, needs to adapt the segment size of the retransmission.
      Using the reported size in the last Packet Too Big message,
      however, can lead to further losses as there might be smaller PMTU
      limits at the routers further along the path.  This would lead to
      loss of all retransmitted segments and therefore cause unnecessary
      congestion as well as additional packets to be sent each time a
      new router announces a smaller MTU.  Any packetization layer that
      uses retransmission is therefore also responsible for congestion
      control of its retransmissions [RFC8085].

This would now describe the issue without getting into defining an algorithm.

Comments?

Bob

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------