On Tue, Feb 2, 2010 at 8:54 PM, Robin Whittle <r...@firstpr.com.au> wrote: > This is a response to Fred's message: > > Re: [rrg] SEAL critique, PMTUD, RFC4821 = vapourware > http://www.ietf.org/mail-archive/web/rrg/current/msg05907.html > > in which he shows that the failure of RFC1191 PMTUD is far > more prevalent than I had imagined: > > Some servers sending DF=0 packets (eg. 1470 bytes). > > Presumed dropping of PTBs in some networks. > > Some servers failing to respond properly or at all to PTBs. > > Perhaps tunnels which do not generate PTBs to the sending > host (which may be the entry router of an outer tunnel). > > It seems the Internet is getting by with dodgy assumptions about > packet sizes which enable everything to work (mostly) despite > these failings. > > I can't see how we could transition to jumboframes in the DFZ > with the current messy situation.
the packet size at the DFZ can go to any larger size it wants... in fact there are at least 2 large US carries (with global presence) that have MTU on all core/internal links >9000. The problem, that I've experienced/seen, is in edge connected places, and where tunnels exist. Often the tunnels crop up in v6 discussions, or in v4 vpn (ipsec) scenarios. There's a reason that the MSS you see upon tcp setup to most 'large' content provider hosts is < 1470 ... tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 23:50:18.826948 IP (tos 0x10, ttl 64, id 31860, offset 0, flags [DF], proto TCP (6), length 60) my.ip.41646 > large.content.ip.http: S, cksum 0xc950 (correct), 3573990180:3573990180(0) win 5840 <mss 1460,sackOK,timestamp 747355984 0,nop,wscale 7> 23:50:18.834402 IP (tos 0x0, ttl 53, id 54699, offset 0, flags [none], proto TCP (6), length 60) large.content.ip.http > my.ip.41646: S, cksum 0x9353 (correct), 686478021:686478021(0) ack 3573990181 win 5672 <mss 1430,sackOK,timestamp 2149169897 747355984,nop,wscale 6> Note he squashes me to mss=1430, yes MSS != MTU, but... it's there because raising it runs into MTU bottlenecks for a portion of users. -Chris _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
