RINA - scott whaps at the nanog hornets nest :-)

Michael Hallgren m.hallgren at free.fr
Sat Nov 6 14:27:37 CDT 2010


Le samedi 06 novembre 2010 à 12:15 -0700, George Bonser a écrit :
> > Sent: Saturday, November 06, 2010 9:45 AM
> > To: nanog at nanog.org
> > Subject: Re: RINA - scott whaps at the nanog hornets nest :-)
> > 
> > On 11/5/2010 5:32 PM, Scott Weeks wrote:
> > >
> > > It's really quiet in here.  So, for some Friday fun let me whap at
> > the hornets nest and see what happens...>;-)
> > >
> > >
> > > http://www.ionary.com/PSOC-MovingBeyondTCP.pdf
> > >
> > 
> > SCTP is a great protocol. It has already been implemented in a number
> > of
> > stacks. With these benefits over that theory, it still hasn't become
> > mainstream yet. People are against change. They don't want to leave v4.
> > They don't want to leave tcp/udp. Technology advances, but people will
> > only change when they have to.
> > 
> > 
> > Jack (lost brain cells actually reading that pdf)
> 
> I believe SCTP will become more widely used in the mobile device world.  You can have several different streams so you can still get an IM, for example, while you are streaming a movie.  Eliminating the "head of line" blockage on thin connections is really valuable. 
> 
> It would be particularly useful where you have different types of traffic from a single destination.  File transfer, for example, might be a good application where one might wish to issue interactive commands to move around the directory structure while a large file transfer is taking place.
> 
> If you really want to shake a hornet's nest, try getting people to get rid of this idiotic 1500 byte MTU in the "middle of the internet"


I doubt that 1500 is (still) widely used in our Internet... Might be,
though, that most of us don't go all the way to 9k.

mh


>  and try to get everyone to adopt 9000 byte frames as the standard.  That change right there would provide a huge performance increase, load reduction on networks and servers, and with a greater number of native ethernet end to end connections, there is no reason to use 1500 byte MTUs.  This is particularly true with modern PMUT methods (such as with modern Linux kernels ... /proc/sys/net/ipv4/tcp_mtu_probing set to either 1 or 2).
> 
> While the end points should just be what they are, there is no reason for the "middle" portion, the long haul transport part, to be MTU 1500.
> 
> http://staff.psc.edu/mathis/MTU/
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20101106/4e0a38a8/attachment.bin>


More information about the NANOG mailing list