Prev-20 Home Next-20 1 msg BGP issues qwest in Burbank, CA 1 msg Looking for Yahoo-SOC contact 1 msg Cachefly Contact 2 msg auth*.ns.uu.net 1 msg auth00/auth100.ns.uu.net down ? 3 msg PCH BGP Archive down? 1 msg Looking for Flickr contacts 2 msg Charter - Southern Oregon routing issues 1 msg Google Contact 1 msg Bob Crooks/SaskTel/CA is out of the office. Microsoft.com PMTUD black hole? \ Nathan Anderson/FSR (6 May 2008) . \ Brandon Butterworth (6 May 2008) . . \ Iljitsch van Beijnum (6 May 2008) . . . \ Nathan Anderson/FSR (6 May 2008) . . . . \ Nathan Anderson/FSR (6 May 2008) . . . . \ Iljitsch van Beijnum (7 May 2008) . . . . . \ Nathan Anderson/FSR (7 May 2008) . . . \ Bjørn Mork (7 May 2008) . . \ Nathan Anderson/FSR (6 May 2008) . \ Robert Bonomi (6 May 2008) . . \ Tomas L. Byrnes (7 May 2008) . . . \ Marshall Eubanks (7 May 2008) . . . \ Nathan Anderson/FSR (7 May 2008) . . \ Nathan Anderson/FSR (7 May 2008) . . . \ Randy Bush (7 May 2008) . . . \ Glen Turner (7 May 2008) . . . . \ Mark Newton (7 May 2008) . . . . \ Patrick Giagnocavo (7 May 2008) . . . \ Rich Kulawiec (7 May 2008) . . . . \ Nathan Anderson/FSR (7 May 2008) . . . . . \ Michael Sinatra (7 May 2008) . . . . . . \ Iljitsch van Beijnum (7 May 2008) . . . . . . . \ Tomas L. Byrnes (7 May 2008) . . . . . . . . \ Nathan Anderson/FSR (7 May 2008) . . . . . . . . . \ Iljitsch van Beijnum (7 May 2008) . . . . . . . . . . \ Nathan Anderson/FSR (7 May 2008) . . . . . . . . . \ Tomas L. Byrnes (7 May 2008) . . . . . . . . . . \ Iljitsch van Beijnum (7 May 2008) . . . . . . . . . . . \ Tomas L. Byrnes (7 May 2008) . . . . . . . . . . \ Nathan Anderson/FSR (7 May 2008) . . . . . . . \ Tomas L. Byrnes (7 May 2008) . . . . . . . . \ Nathan Anderson/FSR (7 May 2008) . . . . . . . \ Bjørn Mork (8 May 2008) . . . . . . . . \ Joel Jaeggli (8 May 2008) . . . . . . . . . \ Iljitsch van Beijnum (8 May 2008) . . . . . . . . . . \ Smith, Donald (8 May 2008) . . . . . . \ Hank Nussbacher (8 May 2008) . . . . . \ Deepak Jain (7 May 2008) . . . . . . \ SML (7 May 2008) . . . . . . \ Tony Finch (8 May 2008) . . . . . . . \ Blaine Christian (8 May 2008) . . \ Stephen Sprunk (7 May 2008) . \ Iljitsch van Beijnum (7 May 2008) . \ Nathan Anderson/FSR (7 May 2008) . . \ Tomas L. Byrnes (7 May 2008) . . . \ Nathan Anderson/FSR (7 May 2008) . . . \ Matthew Petach (12 May 2008) . \ Michael Sinatra (7 May 2008) . \ Scott Weeks (8 May 2008) . \ Janet Sullivan (8 May 2008) . . \ Niels Bakker (8 May 2008) 4 msg Strange network behaviour 1 msg Was Burma off the air due to the Cyclone ? 17 msg OSPF minutia, and, technote publication venues 2 msg Deadline Extension UBICOMM 2008, September 29 -... 1 msg [Fwd: Re: outages] 2 msg outages 21 msg Did Youtube not pay their domain bill? 9 msg Introducing latency for testing? 33 msg fair warning: less than 1000 days left to IPv4 ... Prev-20 Home Next-20

Prev-Msg Prev-Thread Nanog May-2008 Next-Thread Next-Msg Subject: Re: Microsoft.com PMTUD black hole? Group: Nanog From: Nathan Anderson/FSR Date: 7 May 2008 Iljitsch van Beijnum wrote: > No. This would add significant delay because you'd have to give the > other side enough time to respond to the large packet (also sending a > large packet on something like GPRS/EDGE is a waste of bandwidth and > battery power) while if there is ICMP filtering, there won't be a > response, which is exactly the reason why we're in this bind in the > first place I admit the idea needs tweaking (at best), and it was just a stray thought :-), but 1) even if there is ICMP filtering happening way at the other end, I (the TCP initiator) will still get a response from the router in the middle (RITM) that is reducing the total path MTU if I try to send a packet through it larger than the actual path MTU, and 2) if I don't get a response to my single large packet (either from a RITM or the other end) in a timely fashion (less than a second?), then the client/initiator may just assume that path MTU == local MTU and will set its MSS accordingly (which is no different than what is happening now), until it has a reason to think differently. Also, if there is already something in the local PMTU cache for a single host address, I'm not sure I follow why it would be a bad idea for the TCP initiator to consult that cache when preparing the SYN. Although, on second thought, I suppose it is possible (and, in more than a few cases, likely) that in instances of route path asymmetry, the PMTU of the path from the initiator to the server may be different than the PMTU of the path back from the server to the client. Hmmm. Okay, scratch that idea then. :-P -- Nathan Anderson First Step Internet, LLC nathana _______________________________________________ NANOG mailing list NANOG http://mailman.nanog.org/mailman/listinfo/nanog Prev-Msg Prev-Thread Nanog May-2008 Next-Thread Next-Msg

© 2004-2008 readlist.com