Subject: Re: put on your PMTU discovery thinking caps

From: der Mouse <[email-masked]>
Date: Fri, 4 Dec 1998 09:15:16 -0500 (EST)

> [...] pitfalls & problems of implementing PMTU discovery [...]

> Even though some of these problems aren't related to TCP
> implementation, some are, and it's not clear there's a better home
> for discussing them than tcpimpl.

...especially since discussing how to make a PMTU implementation deal
with them *is* squarely in tcpimpl's charter (at least as I understand
it).  The difference between a black hole due to an overloaded ATM
switch and a black hole due to firewalled ICMP may be interesting in
some respects, but the end systems really don't care about details of
*why* their packets aren't getting through; all they care is *that*
they aren't, and they're not hearing back about it.

Besides, how to do IP-over-ATM in a way that doesn't suffer from such
problems is arguably on-charter anyway. :-)  If enough ATM cells make
it through to reconstruct the packet's headers, you can send back a
meaningful ICMP without needing to get all of the payload.  I'm not
sure which ICMP you should send, though.  Need-frag doesn't really
apply.  Source quench, maybe, since it amounts to "I'm overloaded"?

					der Mouse

			       [email-masked]
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Danny McPherson <[email-masked]>
Date: Tue, 15 Dec 1998 16:30:54 -0700

Note that ISIS-WG is not "putting this kind of test in a routing protocol", 
it's been there for quite some time.  We're merely leaving it until something 
better comes along.  It is quite useful, though.

-danny

> PS: I just saw a note in the is-is WG where they discussed making the
> HELLO packet max size, just to detect his problem. I'm not sure if
> putting this kind of test in a routing protocol is a good idea,
> but having a widespread test would be good.