Re: Reopening jumbo frames in IS-IS

[Fred Baker <fred at cisco.com>]

On Jul 15, 2005, at 10:59 AM, Stephen Sprunk wrote:

> It seems fair to me to allow jumbos to be on by default iff there  
> were a standard means to determine that the other host also  
> supports them.

The issue isn't the other host; there usually is a way to determine  
that, like a TCP MSS negotiation. The issue is the network - is there  
some buried switch that won't support them? Is there a tunnel in the  
path that reduces the MTU below what the end hosts expect?

I tend to like draft-ietf-pmtud-method-04.txt's proposal, although I  
tend to think it is a bit over-optimized. Basically, send a large  
packet every so often and see if it gets through. If it demonstrably  
does, you can decide to use them in regular conversation. Otherwise,  
do what works. Thinking in terms of TCP, we now suggest that TCP  
sessions send 2-4 segments in their first burst. well, gee. What if  
the session sent a 9000 byte packet plus three 1460 byte packets? The  
Ack would either report something 9K into the session or something 4K  
into the session. Seems like an excellent start to me... Or, have the  
delivery API include with it the size of the largest fragment folded  
into a delivered datagram. If the number falls, the receiving TCP  
could renegotiate the MSS. Maybe that's too simple.