After spending some time on comparing MPD and poptop, I've found the
following:

- the MTU issue should probably be blamed on Windows XP. poptop
experiences the same problem once you disable tcpmssfixup in ppp.conf
(by default it's enabled). MPD 3.17, with mssfixup enabled, works as
well. Even though the MSS fixup patch is not the perfect solution to
the problem, it's still better than the +4/+6 MPD patch, which causes
bigger packets to be sent to the client than what it agreed upon
receiving. I wonder how Windows 2000/2003 RAS services handle this...

- MPD definitely needs the ng_pptpgre patch to disable PPTP windowing
and delayed ACKs. Otherwise, the 50% packet loss issue pops up again
in most cases (no matter whether you're connecting via 100 Mbps
Ethernet or an analog modem)

- as far as performance is concerned, MPD without delayed
ACKs/windowing is as fast as poptop (measurements over an analog
modem connection with a RTT of about 180 ms confirmed that). Where
bandwidth between the client and the PPTP server is not an issue, MPD
is faster because it handles data in the kernel (for example, on a
WRAP board: 4.33/4.08 Mbps with poptop, and 9.53/8.25 Mbps with MPD -
128-bit encryption)

In conclusion, we should upgrade to MPD 3.17, use the ng_pptpgre
patch, disable delayed ACKs, enable mssfixup, and the PPTP problems
should be gone for good - or so I hope.

There's just one catch left: there seems to be a problem with PPPoE
support in MPD 3.16 and up. I sometimes experienced this bug:

<http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/62477>

after upgrading to 3.17 when rebooting m0n0wall (I use PPPoE on the
WAN side). Killing and restarting MPD (by pressing the Save button on
the WAN setup page) took care of the problem, but interestingly, it
didn't happen every time. Sometimes I could reboot 5 times without
seeing the problem... nasty. It never happens with 3.14 though.

The MPD mailing list seems to be down at the moment - I'll consider
adding my "me too" about this problem once it's up again.

- Manuel