[104339] in North American Network Operators' Group
Re: [NANOG] Microsoft.com PMTUD black hole?
daemon@ATHENA.MIT.EDU (Nathan Anderson/FSR)
Wed May 7 14:51:11 2008
Date: Wed, 07 May 2008 11:50:34 -0700
From: Nathan Anderson/FSR <nathana@fsr.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <600402FF-DE0C-4BAD-B1FE-081DE07724C6@muada.com>
Cc: nanog@merit.edu
Errors-To: nanog-bounces@nanog.org
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@fsr.com
_______________________________________________
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog
