Re: [quicwg/base-drafts] PMTUD (#64)

[ianswett <[e-mail]>]

On Tue, Dec 13, 2016 at 11:25 AM, martinduke <[e-mail]>
wrote:

> I think I'd like a 'trust but verify" approach to path MTU. In an ideal
> case, QUIC would get the ICMP message and verify that it really could get a
> non-fragmented packet through with that size. As long as the size was
> larger than the chosen handshake size, it would try it.
>
> Stacks should ignore ICMP messages that *increase* the PMTU. The "only"
> issues with ICMP are non-conforming routers, and attackers (especially
> "off-path" attackers) that drive the MTU down to the minimum value.
>
Right, what I had in mind was completing the handshake, then sending out a
RFC 4821 style PMTUD packet and if an ICMP message comes back, try that
size one more time to see if it gets through.  If the original probe got
through, even though an ICMP message was received, then QUIC should ignore
the ICMP message and stick with the probed size.

> Some of what we've discussed(ie: padding the CHLO and SHLO and setting the
> DF bit) is what the implementation does today, and not including it in the
> draft was an oversight we really need to fix.
>
> That's great, but again, CHLO and SHLO will often have long RTOs, so
> loss-based MTU discovery is uniquely ill-suited to these packets.
>
Today, most paths either block all UDP or support largish(ie: >1400 byte)
MTUs, so there needs to be good handling for timeouts.  Use of ICMP
messages in the handshake could be useful when available, but it's an
optimization to allow a few extra people to speak QUIC, at least on today's
public internet, where it's necessary to have a TCP fallback.  But we
should specify what should happen in a fallback free world where ICMP is
available to clients and servers.

> Actually, QUIC's congestion control(and I believe FreeBSD's) operates in
> bytes, not MSS. But I agree it's likely the network and host are more
> efficient with larger packets.
>
> I believe there's already a comment that QUIC congestion control is poorly
> spelled out in the draft. But the draft says it uses TCP congestion
> controls, which define their initial cwnd in multiples of MSS. In the
> absence of ABC, which is not listed in the draft, then acknowledgments
> increment cwnd in multiples of MSS as well.
>
Good point, I'll make sure ABC gets added along with a more fleshed out
congestion control section.

> But please do a pull request with what you describe above, because I think
> you're going in a good direction, and it's just a matter of working out
> some details, which is easy to do in the comments of a PR.
>
> It might take me a week or two to get to it, but I will do so. Thanks for
> the encouragement!
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/64#issuecomment-266785694>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ATJJcb2D_Sm8WYSNaxwvZAf4ROVYPgouks5rHscDgaJpZM4LCCRR>
> .
>


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/64#issuecomment-266797525