Hi Wesley, > -----Original Message----- > From: rrg-boun...@irtf.org [mailto:rrg-boun...@irtf.org] On Behalf Of Eddy, > Wesley M. (GRC-MS00)[ASRC > AEROSPACE CORP] > Sent: Friday, January 29, 2010 1:23 PM > To: Dan Wing; 'Robin Whittle'; 'RRG' > Subject: Re: [rrg] SEAL critique, PMTUD, RFC4821 = vapourware > > >-----Original Message----- > >From: rrg-boun...@irtf.org [mailto:rrg-boun...@irtf.org] On Behalf Of > >Dan Wing > >Sent: Thursday, January 28, 2010 10:01 AM > >To: 'Robin Whittle'; 'RRG' > >Subject: Re: [rrg] SEAL critique, PMTUD, RFC4821 = vapourware > > > > ... > >> > >> Where is the evidence that PTB filtering is ever more than a > >> transitory, mistaken, condition? > > > >Sounds like you want a research paper? > > > Here are three for Robin's sake; this issue is well known to the > transport layer folks: > > http://www.icir.org/tbit/tbit-Aug2004.pdf > > http://www.caida.org/workshops/wide/0603/slides/mluckie2.pdf > > http://listserver.internetnz.net.nz/pipermail/ipv6-techsig/2009-October/000708.html
Thanks for pointers to this work. Robin pointed out some of this on the RRG list earlier, but its good to have the additional material. >From Ben Stasiewicz' post on the ipv6-techsig mailing list (above), I retrieved the Alexa list of the top 1M websites and from this took the top 1000 as my sample set. I used the "tbit" tool (http://icir.net/tbit) to run IPv4 Path MTU discovery (PMTUD) tests on each of the top 1000 using the command syntax: # tbit -m 1460 -M 576 -n www.example.com -t PMTUD example.com This command has tbit advertise an MSS of 1460 during the TCP connection, but whenever tbit receives a packet larger than 576 from a website it drops the packet and sends back an ICMPv4 "Fragmentation Needed" (aka "PMTUD") message. The test was to determine how each website in the top 1000 responded to PMTUD messages. Of the websites sampled, I observed the following results: Transfer Fail: 249 (24.9%) PMTUD Disabled: 109 (10.9%) PMTUD Success: 394 (39.4%) PMTUD Fail: 196 (19.6%) Connection Fail: 52 ( 5.2%) The "Transfer Fail" class was mostly due to HTTP 301/302 responses (tbit did not know how to handle these), and in those cases tbit quit before any PMTUD tests were run. I otherwise did not make any effort to diagnose the failures more closely. The "PMTUD Disabled" class included websites that set DF=0 in the IPv4 header, and thereby disabled PMTUD making data packets eligible for fragmentation in the network. The "PMTUD Success" cases correctly implemented PMTUD, but in many cases tbit needed to send multiple PMTUD messages before the website reduced the size of its data packets. In some cases, websites responded to the PMTUD messages in strange ways, including making curious guesses at packet sizes instead of honoring the MTU size advertised in the PMTUD message, turning PMTUD off altogether after receiving a few PMTUD messages, etc. The "PMTUD Failed" cases represented true failures of the website to correctly honor the PMTUD messages, as verified by wireshark captures. This could only happen if the PMTUD messages were filtered in the network and not delivered to the website, or if the website received the PMTUD messages and ignored them. The "Connection Fail" cases represented websites that were unreachable, but may have also included sites that sent large packets that were silently dropped due to a true MTU bottleneck before reaching the test machine. All of this closely agrees with the results documented in "Measuring the Evolution of Transport Protocols in the Internet" (Medina, Allman, and Floyd, ACM Computer Communication Review, April 2005): http://icir.net/tbit/TCPevolution-Mar2005.pdf The end result is that the IPv4 Internet still seems to be vulnerable to PMTUD failures along paths that lead to the top websites in the Internet today. This suggests that PMTUD is likely not being invoked very often in the first place since most links in the Internet configure an MTU of 1500 or larger and few applications send packets larger than that. However, as more and more tunnels over the IPv4 Internet are used the frequency of PMTUD failures is likely to increase as well. Fred fred.l.temp...@boeing.com > -- > Wes Eddy > MTI Systems > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
