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

[Mikael Abrahamsson <swmike () swm pp se>]

On Sun, 7 Nov 2010, George Bonser wrote:

> True, but TCP is what we are stuck with for right now.  Different 
> protocols could be developed to handle the small packets better.

We're not "stuck" with TCP, TCP is being developed all the time.

http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm

> We are starting to move to 10Gig + peering connections.  I have two 10G 
> peering ports currently on order.  "several gigabits/sec" is here today.

I was talking about end users, not network.

> It depends on what those end users are doing.  If they are loading a web
> page, you are probably correct.  If they are an enterprise user
> transferring log files from Hong Kong to New York, it makes a huge
> difference, particularly the moment a packet gets lost somewhere.  At
> some point it becomes faster to put data on disks and fly them across
> the ocean than to try to transmit it by TCP with 1500 byte MTU.  Trying

Oh, come on. Get real. The world TCP speed record is 10GE right now, it'll 
go higher as soon as there are higher interface speeds to be had.

I can easily get 100 megabit/s long-distance between two linux boxes 
without tweaking the settings much.

> I disagree with that statement because I believe that the next few years
> will see an increased demand for high-bandwidth traffic that needs to be
> delivered quickly (HDTV from Tokyo to London, for example).

MTU and "quickly" has very little to do with each other.

> 3Meg/sec.  If they could increase the MTU to 9000, they might get 
> 15Meg/sec.

Or they might tweak some other TCP settings and get 30 meg/s with existing 
1500 MTU. It's WAY easier to tweak existing TCP than trying to get the 
whole network to go to a higher MTU. We do 4470 internally and on peering 
links where the other end agrees, but getting it to work all the way to 
the end customer isn't really easy.

As with IPv6, doing the core is easy, doing the access is much harder.

> it might break something.  Increasing MTU never breaks PMTUD.  PMTUD is 
> only needed because something in the path has a *smaller* MTU than the 
> end points.  The end points don't care of the path in between has a 
> larger MTU.

But in a transition some end systems will have 9000 MTU and some parts of 
the network will have smaller, so then you get problems.

--
Mikael Abrahamsson    email: swmike () swm pp se