AFCP vs. TCP/IP

[Michael McGinley]

We have recently migrated from an HP3000 to an HP9000.
Our existing data 56 point to point data lines are getting hammered now that we use IP as opposed to AFCP.
Problem is, we now have to prove that AFCP was a more efficient protocol in order to upgrade our data lines.
First of all, was AFCP more efficient?
Secondly, if it is, is there any documentation out there to prove it?

[Jeff Schussele]

Hi Michael,

I'll admit that I know nothing about AFCP. But one should not focus on effciency.
Of what benefit is 99% of 1,000,000 compared to 50% of 1,000,000,000?
I'd think it's WAY past time to dump 56k lines & start looking at DSL & Cable.
The other thing to consider is the TYPES of traffic the comm lines can carry.
HELL, if I had my way, I'd have Sonnet rings thru my abode & would prefer ATM. If for nothing else than the redundancy.
BTW what are they raping..err..charging for 56K lines nowadays?

My 2 cents,
Jeff

[Tim Sanko]

Jefe,

El jefe del mundo You are a joy to my susceptable senseless humor, but you are right on if the person is inside the U.S. If one is outside the U.S. this technology may not be available. The difference between MPE and HPUX is "HUMONGOUS" in the networking arena.

I wish I had our old benchmarks when we went to IP from AFCP to show you. The collection was via database puts via dialup. There was a > 30% hit. You are right about everything except the location, which is unmentioned.

Keep Us Smiling

Tim

[Michael McGinley]

Thanks Jeff. That is the game plan. We are proposing to go w/ a VPN solution. The 56k lines are stable but pricey. Problem is we invested in quite a few DTC 72 's and they want to get a few more years out of them.

Tim, I wish you held on to your benchmarks also. I just can't find any documentation for what is so obvious. HP wants to charge us for this information. Thanks for what you gave me in the mean time.

Take it easy.

[rick jones]

Some things that may help tuning the TCP/IP stuff on the 56K lines:

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_netstat.txt
ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_ndd.txt

In particular, look for the TCP retrans, and consider dropping the default TCP socket buffer (window) size and perhaps adding -B switches to your ftp commands if doing file transfers. Likely one does not need a 32KB window to keep a 56k link full and if you have lots of concurrent TCP/IP flows...

[W.C. Epperson]

Hi, Rick. Long time, no see.

Other factors being equal, a routable, error-correcting protocol like TCP/IP will always be less "efficient" on a raw basis than a non-routable flow-control protocol like AFCP. And the only way to make AFCP routable was to encapsulate it in UDP, so....

I certainly understand the survival of 56K lines. I still had a couple of DC-continuity LAD circuits until a year or so ago when we replaced our old Internet T-1 with a DS3. We had discovered that the 56K-rated LAD circuits would actually run T-1....

[Ron Kinner]

If you can find out how many bytes in the AFCP header and its maximum packet size you could compare it to the average TCP/IP header.

Even without that information we can make a decent guess. HP says AFCP is optimized for its purpose. I assume it just needs a source and destination and check sum so we can easily squeeze all of that into no more than 12 bytes. I have no clue as to the maximum size of the data packet but this is old technology so let's assume 600 bytes. So with AFPC we have a total packet size of 612 bytes. Let's assume the 56K line is running at 90% capacity under AFCP. Remember this is 56 K bits/second or 7 K bytes/second so 90% is 6.3 K bytes/second. Dividing by 612 bytes we get 10.3 packets /second. Now we know designers are lazy so I expect that HP just encapsulates the AFCP packets into TCP/IP which adds at least 48 more bytes to each packet so we have a new packets size of 660 bytes. In order to maintain our previous level of service we have to send the same number of packets (actually a few more because each TCP session take 3 extra packets to set up and 4 to take down but we will leave them out for now.)660 * 10.3 = 6798 Bytes /sec. That doesn't look too bad does it? Only an increase of from 90% usage to 97%. However that has a much bigger effect on the user than you might expect. Lets assume the pure AFCP users were used to a delay of 5 seconds where 4 seconds was processing time and only 1 second was due to the delay of transmission. D = D0/(1-U) where D is the delay at a usage of U and D0 is the idle delay. So if D = 1 and U = .9 then D0 = .9 Now change U to .97 and D becomes 30 so our total delay is now 34 seconds. This is a fairly conservative estimate. Actual increase in delay will be greater since I left out the TCP/IP session setup and teardown packets and could be much more if your maximum AFCP were smaller than 600. Plus traffic is bursty so some packets will be dropped and have to be resent which will slow things down a lot more.

Bottom line is that if changing to TCP/IP caused your datalines to be "hammered" then you were probably already running them at near maximum and would have had to upgrade them in the near future anyway.

Ron

PS I got the delay formula from P 151 in a textbook called "Computer Networks and Internets" by Douglas E. Comer. Copyright 1997.