Re: Supernet block sizes - recommendations?
From: aggarwal@nisc.jvnc.net (Vikas Aggarwal) Subject: Re: Supernet block sizes - recommendations? To: Daniel.Karrenberg@ripe.net (Daniel Karrenberg) Date: Fri, 14 May 93 9:28:44 EDT Cc: regional-techs@merit.edu, local-ir@ripe.net [...] Usually these arguments do the trick-- its a matter of technical sense prevailing over 'I want a class B' pride.
We ought to have a better response to the claim: "I want a class B to improve performance, (because I can easily make my UNIX software use larger MTUs)." -tjs
Usually these arguments do the trick-- its a matter of technical sense prevailing over 'I want a class B' pride.
We ought to have a better response to the claim: "I want a class B to improve performance, (because I can easily make my UNIX software use larger MTUs)."
If this is critical, you can suggest modifying the constants in /sys/netinet/in_proto.c (at least on Suns running SunOS 4.x): /* * Default TCP Maximum Segment Size - 512 to be conservative, * Higher for high-performance routers */ int tcp_default_mss = 512; Yes, bumping up tcp_default_mss will do so for all destinations (unless the final destination requests a lower mss). This is not without its problems: it may have a detrimental effect on traffic passing through paths with a lower MTU (causing fragmentation, which we know to be harmful), as well as cause extra serialization delay on slowish serial links, causing slower response time for simultaneously running interactive sessions. The correct fix is to implement MTU discovery, I guess, but not many vendors do that yet... - Havard
participants (2)
-
Havard Eidnes
-
tjs@msc.edu