<div dir="ltr"><div class="gmail_default" style>On Fri, Jan 18, 2013 at 2:08 AM, Sam Wilson <span dir="ltr"><<a href="mailto:Sam.Wilson@ed.ac.uk" target="_blank">Sam.Wilson@ed.ac.uk</a>></span> wrote:<br></div><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">In principle PMTUD is the more technically elegant way - finding out what's out there and adapting to it. Mandating a fixed MTU is actually not simple since I guess you'd have to allow for tunnelling, extension headers and so on that might be added along the path and which would rob space from the data field. You'd have to require a physical MTU larger than the logical MTU with enough headroom to allow for extra overhead, and *still* have a method of dealing with any overflows en route caused by, say, multiple layers of tunnelling.</span><br>
</div></div>
<br>
It all gets a bit awkward.</blockquote><div><br></div><div style>Agreed. Reality is often messy.</div><div style><br></div><div style>My personal opinion is that we should rely on path MTU to work but, due to the latency impact, try not to rely on it too often (and so, for example, lower the RA MTU on networks that *know* they are behind a tunnel).</div>
<div style><br></div><div style>I don't know how many people agree with me though. And I also don't know if we can depend on PMTUD to work if we don't rely on it often.</div></div></div></div>