ON THE WIRE / BILL ALDERSON AND J. SCOTT HAUGDAHL

On The Wire Goes Out On The VINE

Q : We're an international corporation with more than a dozen United States sites linked to our U.S. headquarters data center. We are beginning to roll out routers that are configured to route IP and transparently bridge non-IP protocols. The non-IP protocols are Banyan Vines, our enterprise operating system, IBM

Systems Network Architecture (SNA) for host connections, and some isolated Novell NetWare. Currently, some of our Banyan servers have their own WAN links, but we are moving to multiprotocol routers. Our routers will be upgraded to route Vines, but not for several months.

But meanwhile, we have abysmal performance and often can't even complete a file copy to or from our Banyan servers from some of our remote locations. Help, we're tangled up in VINES!

Scott: Well, Bill, it sounds like these folks are up a tree, huh?

Bill: You got that right. Let's see if we can find out what's out "on the vine."

Scott: When reading or writing file data, Banyan uses a sliding window of data blocks, permitting up to four unacknowledged blocks of data to be sent in either direction. Once the sender sends all four unacknowledged data blocks, it must wait for an acknowledgment (ack) for at least one block before sending another.

Bill: But, if an ack doesn't arrive within a given amount of time, the sender retransmits the unacknowledged packet(s) again, right?

Scott: Right, and that retransmit time depends on the routing metric between the workstation and the server.

Bill: In fact, Banyan's Routing Update Protocol (RTP) assigns a routing metric for the speed of each link based on the approximate round-trip delay across a given media. Routers then use the combined metrics to determine the best route to a specific network. Workstations and servers use the combined metrics between them to establish the retransmit time-out length. In other words, communicators determine how long they should wait before assuming a packet is lost.

Scott: Each metric represents a 200-millisecond time period. Metrics are assigned based on the relative speed of the media. Generally speaking, speed equates to time, since a fast media should be able to transmit a packet faster than a slower one. Banyan's RTP designers decided, for instance, that Ethernet and 16-MB Token-Ring gets a metric of two, a 4-MB Token-Ring a metric of four and a 56-Kbps link gets a metric of 45. Thus, to Banyan a 56-Kbps link metric of 45 equates to a 9,000 millisecond- (nine-second) round-trip delay. Come to think of it, isn't that a far longer delay than a 56-Kbps link would actually incur?

Bill: Yeah, as long as these metrics are used consistently it should work fine for route determination. Don't forget, we network implementors and troubleshooters didn't think this stuff up. Some design constraints are left with the original protocol designers who may have forgotten some of the reasons for assigning certain metrics!

Scott: We do know that when a workstation and server connect, the metrics of all intervening routers are used to set the retransmission time-out. For instance, if one is on a local Ethernet, the retransmission time-out is set to retransmit fairly quickly, as a metric of two turns out to be 2 x 200 milliseconds (ms) or 400 ms.

Bill: And if a workstation and server are separated by two Ethernets and a 56-Kbps WAN, the total metrics are summed to arrive at the retransmit time-out value; that would be 2 + 45 + 2 = 49 x 200 ms, for a total of 9,800 ms, or 9.8 seconds. In this case, no retransmission would occu r until the sender waited 9.8 very patient seconds!

Scott: Now, for what we found "on the VINE"--the basic setup is a server on Ethernet, crossing a 56-Kbps link to another Ethernet to the workstation.

Bill: As the workstation attempts to copy a modest size file from the server, our four unacknowledged packets queue in the router buffer awaiting transmission across the 56-Kbps link. And while those packets sit in the buffer, the retransmission timers are ticking!

Scott: Several packets make it through and each sends the requisite "thank you" acks back to the server. But, just as you might expect, it takes a long time to transmit each 1,500-byte packet, which is a large Ethernet packet, across the slower 56-Kbps link. After a few packets cross successfully and the WAN link saturates, the server starts getting uncharacteristically impatient and it starts retransmitting some unacknowledged packets in the neighborhood of 360 ms.

Bill: But why is the server retransmitting at 360 ms instead of waiting the 9.8 seconds as we already noted?

Scott: Good question. In fact, I'd call it the "64-Kbps" question. Here's where we take a careful look at the technology carrying the packets.

Bill: Let's see, our customer has implemented bridging until the router supports VINES routing, sożEureka! It's the transparent bridging!

Scott: Meaning that the server thinks the workstation is on the same Ethernet!

Bill: So, if it doesn't get an ack within 400 ms, it retransmits using the Ethernet-to-Ethernet metric, causing the transparent bridge to queue retransmissions for multiple packets, slowing the link further until hitting the retransmit limitż

Scott: Which makes the server think the path to the workstation, or the workstation itself, is no longer alive. It then aborts and loses its connection.

Bill: Hey, Scott, think we ought to statically configure the Banyan server for a higher metric on the Ethernet port?

Scott: No cigar. Banyan will only let us statically configure a tunneled route thro ugh an IP, IPX or source route bridged network, but, not across a transparently bridged network!

Bill: Looks like one of those times when even though we diagnose the problem down to the millisecond, and know the solution, we're simply unable to write new code for the vendor, huh?

Scott: Yeah, aside from a Banyan patch or waiting for new routers, the only other possible solution is to use VINES' IP tunnel option to cross the bridge in an IP packet with a correctly adjusted metric.

Bill: Hey, don't forget about a possible switch to IPX, or Token-Ring and source route bridges!

Bill and Scott are principals of Pine Mountain Group, and spend their time troubleshooting and optimizing large networks, training end users in protocol analysis, and developing tools to allow users to make better use of their protocol analyzers. Portions of the actual trace files that were discussed in this column are available in the Network Computing On the Wire CompuServe forum (GO OTW) or via Pine Mountain Group's Home Page on the Web (http://www.pmg.com). These files can be loaded into your own analyzer. This month's file is VINES.ZIP and contains VINES trace files for various protocol analyzers. These files are copyrighted by Pine Mountain Group, and may not be used for any commercial purposes. Additional files may be made available from time to time, at our discretion. Please e-mail us at otw@pmg.com.