Re: [pmtud] Improvement for the current PMTUD mechanism

At 03:23 p.m. 10/10/2005, John Heffner wrote:

> > (As a side note, I'm not sure the behavior you describe would happen in
> > practice. Particularly because of TCP's slow-start algorithm. As there are
> > only a few segments "in flight" just after connection establishment or a
> > period of idleness, in many cases there won't be enough duplicate ACKs for
> > fast retransmit to be triggered. Anyway, as the fix to the point you raised
> > is pretty simple and inoffensive, that's the easier way to go).
>
>It does feel like a corner case, probably difficult to trigger.  But I think
>it would be hard to prove it never happens, particularly if you consider all
>possible future behaviors of TCP (with modified slow start or retransmit
>algorithms).

Even then, I'm not sure this is behavior would be a bug, or a feature.

If one out of every four packets gets forwarded through the small-MTU link, 
then one should still consider whether assuming the Path-MTU is that of the 
smallest-MTU path is better than assuming the Path-MTU is that of the 
larger MTU.

If on one path the MTU is, say, 296 bytes, and on the other path the MTU 
is, say, 18000 bytes, then someone might argue it's better to lose one 
packet out of four, than to waste a large amount of bandwidth in headers of 
lots of 296-bytes packets.

Even then, it's so simple to address this case (by disabling 
fast-retransmit when there's a pending ICMP message) that I don't think one 
should worry about it. Disabling fast-retransmit while there's a pending 
ICMP PTB is simply being more conservative.

Kindest regards,

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

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