Re: [pmtud] Improvement for the current PMTUD mechanism

John,

>One thing to consider is the case where one flow is traversing multiple paths
>concurrently.  In the algorithm you describe, in this case it's likely a host
>will ignore the ICMP PTB messages since it can still make progress, but
>ignoring them is clearly the wrong thing to do and will drastically hurt
>performance.

No, it won't. As long as the segment claimed by the ICMP PTB has been 
dropped (which will always be the case for legitimate ICMP PTBs), the 
Path-MTU will be updated.

Or am I missing something?

>It might be a good idea to add some text about layering issues. Classic PMTUD
>occurs at both the IP and TCP layers.  In implementations with which I'm
>familiar, the ICMP message is processed by the IP layer, updating the pmtu in
>the route cache, then the message is demuxed and passed down to TCP, which
>updates is MSS and retransmits the packet.  To implement these the 
>algorithm you
>describe, you'll need the ability for TCP to be able to "override" the IP
>layer's idea of the pmtu.

This is not the case in NetBSD's and OpenBSD's PMTUD implementations. I 
can't speak for Linux and FreeBSD, though.

>One small suggestion is that it might be natural to use "R1" from RFC 1122
>instead of specifying the new variable MAXSEGRTO.  This variable indicates
>how long to wait before deciding the connection is making no progress.  This
>may be what you're looking for, or possibly not.

I think R1 has a different meaning.

MAXSEGRTO would be set, in principle, to 1. That is, you would wait for one 
RTO, which is the amount of time you assume is enough for the segment to 
get to the remote endpoint and get acknowledged.

MAXSEGRTO could beset to some larger value in case you assume more varying 
network conditions, either because of the networking environment, or 
because of congestion caused by an attacker hitting your link.

Thanks so much for your feedback!

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org

_______________________________________________
pmtud mailing list
pmtud@ietf.org
https://www1.ietf.org/mailman/listinfo/pmtud