Samsung finally released the Windows Mobile 6 upgrade for the AT&T BlackJack yesterday. Having spent a whopping 6 hours playing with it, I can say this is upgrade is well worth the trouble. If you have a BlackJack, upgrade immediately!

Upgrading your phone is a smooth process, if follow the steps Samsung lists here, with a few caveats. First, backup all your data. This upgrade will wipe your phone, so you will lose all data and installed programs. Second, make sure you have links and license keys for any software you have added to your phone. You will need these to reload your software. Third, remove your SIM card before starting the process. You risk losing data on the card if you do not. After that, the upgrade is incredibly straight forward.

There are many differences between Windows Mobile 5 & Mobile 6. The Microsoft Mobile 6 Comparison Guide highlights the main differences. The upgrade will install Mobile 6 Standard edition on your phone. This is still not as feature rich as the OS you’ll find on Windows Mobile touchscreen devices, because it is optimized for 1-handed operation. Even so, I’ve found many improvements that make the upgrade worthwhile.

Top 10 Reasons to Upgrade to WM6:

1. Office Mobile - We finally can open and edit Word, Excel & PowerPoint files! Mobile 5 could view files with Picsel Viewer, which sucked, but Office Mobile lets you edit on the phone.
2. Improved Internet Explorer - The new version of Mobile IE is much improved. Modern web pages now look normal! Mobile IE5 had poor support for CSS and web pages rarely ever looked right.
3. New Instant Messenger Client - The AT&T IM client now supports AIM, Windows Live, and Yahoo! Messenger. You can also download the Skype 2.2 client here. Make sure you choose the SmartPhone version.
4. Smartfilter - WM6 makes it easier to find messages in your inbox, using smartfilter. Simply type in the word or phase you are searching for, and the message list is filtered for you. Makes it much easier to find a message from your boss! Smartfilter also works in the new Media Player, to help you find a specific song.
5. Company Directory - The new Company Directory feature lets you find contacts quickly from your Exchange Global Address List. In WM5, these searches could take 45 -90 seconds. In WM6, the searches seem much faster, taking 3 -5 seconds.
6. Calendar - The updated calendar rocks! You can finally see invited attendees, and propose new times for meetings. There is also a slick ribbon interface that improves how you visualize your day. You can easily see where you have free time, and where you are triple booked.
7. Information Rights Management - WM6 supports IRM functions, including controlling who can read or forward e-mails and documents. More importantly to me, WM6 can read IRM protected e-mails and attachments. This was a huge problem under WM5. IRM e-mails could not be read at all.
8. Storage Card Encryption - You can automatically encrypt documents stored on your SD card, so they can only be read on your phone.
9. MobiTV & XM Mobile - The new MobiTV and XM Radio Mobile clients make streaming audio and video over 3G useful and practical. I played with the MobiTV demo and I’m hooked. Finally, Fox News anywhere!!!
10. Dozens of minor tweaks and improvements - I am constantly finding minor changes that improve the experience. When reading e-mail, deleting has been bound to the left-function key. This allows for 1-button deletes, which is a huge improvement. Categories now sync from Outlook to the device, rather than maintaining a separate category list on the phone. There is now a Windows Update function, for obtaining WM6 patches from Microsoft.

There are also some features that seem missing in the the Samsung WM6 image. Most notably, WM6 is supposed to support HTML formated e-mails, but in my experience, messages are still rendered as plain text. It is not clear to me if this is a limit of WM6 standard, the Samsung version of WM6, or if I am missing a configuration tweak.

It should also be noted that while it seems to take longer for WM6 to load at boot, I have not found any other performance problems. All-in-all, this is a great upgrade, even if it is a year late.

Update 01/25/2008 - HTML e-mail is working for me on my POP3 account, but not on e-mail sync’d with my corporate Exchange server. This may be a setting in Exchange that is reformatting the messages before I get them, rather than a WM6 issue. HTML e-mail for POP3 works great and renders well, using the new mobile IE engine.

Don’t forget to backup your data first and remove your sim card!!!

Common Availability Definitions:

1. Availability = MTBF/(MTTR+MTBF) (Mean Time Between Failure, Mean Time To Recover). This is a classic definition of availability and is often used by hardware manufacturers when they publish an availability metric for a given server.
2. Availability = (Uptime + Scheduled Maintenance)/(Unscheduled Downtime + Uptime + Scheduled Maintenance). This is an IT centric availability metric where the business can support scheduled downtime after hours. This model works for some types of systems, such as a file server that isn’t needed at night, but it doesn’t work as well for websites, even though many web companies still use this for their SLAs.
3. Availability = Uptime/(Uptime + Downtime). This metric best applies to systems that are needed 24×7 such as e-commerce sites.

Availability is most often expressed as a percentage. Sometimes, people will refer to “four nines” (99.99%) or “five nines” (99.999%). To simplify things, the following table shows the minutes of downtime allowed per year for a given availability level:

Based on the above table, you can see there is a big difference between an SLA specifying 99% availability (88 hours of downtime per year) and 99.9% availability (8.8 hours of downtime per year). But how can we be sure what the expected downtime of the system is? In the most simplistic form, the expected availability of a system equals the expected availability of each of the components of the system multiplied together. So if the system was composed of two servers, and each server had an expected availability of 99%, then the expected availability of the system would be 99% * 99% = 98.01%. Note: I have used the term “expected availaibilty.” We are calculating a future expectation of the system over an extended period of time, not a historical availability. For the rest of this article, I will drop the term expected for brevity, but it is always implied.

The simplistic model above is useful for illustrating the point that downtime is cumulative. In other words, if I expect each component to be down 88 hours/year, and a failure of either component is a failure of the system, then the system has an expected downtime of 174 hours. Why not 176 hours? Well, occasionally both components will be down at the same time.

Real world systems are never this simple. Typically, the system will be comprised of multiple components, some with redundancy, and each with different levels of component availability. Modeling these requires slightly more complicated formulas, but once you have the concepts down, then the actual calculations can be quickly performed in a spreadsheet. Before we move forward, we need some basic notations to simplify our formulas:

Basic Nomenclature
Availability Component 1 = Ac₁
Availability Component 2 = Ac₂
Availability Component 3 = Ac₃
Availability Component n = Ac_n
Availability System = As

Now that that is out of the way, we are ready for our first formula. When a system is made up of n number of components that are each single points of failure then the system availability can be calculated as:

EQUATION #1: As = Ac₁ * Ac₂ * Ac₃ * …Ac_n

Consider a 24×7 e-commerce site with lots of single points of failure. We might model the site as having the following eight components:

If any of these components fails, the website will crash. The expected availability of the site would be 85%*90%*99.9%*98%*85%*99%*99.99%*95% = 59.87%. Note that we are modeling each component as a whole, rather than looking at its parts. We could break down the web service into software (Apache), code (our web site), and hardware (motherboard, hard drives, etc.). For our purposes, complexity does not necessarily improve the model, so we will deal with the service as a whole. Also, for this discussion we will use the third definition of availability above. To our users, it does not matter if the site is down because of maintenance or a hard drive failed.

Assuming we want to keep our jobs, we need to figure out a way to increase this availability. Two obvious targets for improving the site stability would be the web service and the firewall. The question is, what effect would adding another web server have on the availability of this service. This leads us to our second equation. When a system is comprised of two redundant components, then the availability of the system can be calculated as:

EQUATION #2: As = Ac₁ + ((1 - Ac₁) * Ac₂)

Using our example of a web server with an availability of 85%, then adding a second server would increase the availability to: 85% + (1-85%)*85% = 97.75%. The logic behind this is that when the 1st server is down (15% of the time), the second server is still up 85% of the time. This may or may not translate into actual real world availability. For instance, if the web server was down so often because we constantly need to take it offline to deploy new code, then adding a second server should translate to higher availability, because we could deploy code to one offline server, while the other server stays up. In this case, our real world availability increase might be greater than 12.75%. Conversely, if our service is down due to code bugs, then adding a second server could in some cases make the availability worse by exasperating the bug.

The point is that in general if you’ve accurately estimated the availability of the component, then the equation will work. Note also that the equation works even if the components have unequal availability estimates. Assume that the web server has an availability problem because the hardware is undersized. Now assume the second server we purchase has twice the capacity, and we determine that by itself the availability of the new server would be 90%, then our equation changes to: 85% + (1-85%)*90% = 98.5%.

So let’s add this back into our system calculation above. Assume that we add a second web server, and a second firewall, increasing the availability of each component system to 97.75%. Now, the availability of our system would be: 97.75%*90%*99.9%*98%*97.75%*99%*99.99%*95% =79.10%. Better, but still not great. It is hard to achieve any level of high availability when you have single points of failure. So let’s assume that we add a redundant component for all our servers and network equipment. Let’s also assume we add a second ISP for carrier diversity, but we are still within one physical data center. Our availability equation would now be: 97.75%*99%*99.9999%*99.96%*97.75%*99.99%*99.99%*99.75% = 94.3%. Getting better. Removing single points of failure improved our availability of the system from 60% (3506 hours of downtime/year) to 94.3% (500 hours of downtime/year).

Equation #2 above modeled adding a single redundant component. In some cases, we may add more than one redundant component. For example, we may have more than two web servers. In this case, we need to iterate through equation #2 multiple times to find the effect of the additional components, which brings us to our third equation. When trying to calculate the availability of a service with n number of redundant components, we calculate it as:

EQUATION #3: As = Ac_(n-1) + ((1 - Ac_(n-1)) * Ac_n)

In the case of our web service, adding a 3rd server would change the availability to: 97.75% + (1-97.75%)*85% = 99.6625%. Adding a fourth server would increase availability to: 99.6625% + (1-99.6625%)*85% = 99.949%. Note that there is a diminishing level of return. Adding a 2nd server increased availability by 12.75%. Adding a 3rd server only gained us 1.9125%. The fourth server bought us a paltry .2865%. And yet, even with 3 more servers than we need to service our load, we still have not yet achieved the elusive four nines of availability. Designing a highly available system requires us to make individual components highly available AND add redundancy of components. If the individual web server in our example had an availability of 90%, instead of 85%, then the availability of two servers would be 99% and three servers would be 99.99%.

Equations 2 & 3 have a simple flaw, in that they assume a single component can handle the load, and that the load is constant. What if under normal operations, one web server can handle the load, but under peak, we need three servers? Then our availability for three servers under normal load would be 99.775%, but under peak load, the availability would drop back to 85%. Under peak load, the failure of one server would cause a loss of the service, so we drop back to the availability of a single box. What if our peak load required 2 servers? In this case, the availability under peak would be 97.75%. If peak requires two servers, and we have three, then we can lose one server and still be operational, therefore our availability is the equivalent of having two servers. The important concept here is there is an inverse relationship between load and availability.

What should be obvious by now, is that achieving truly high levels of availability (99.9% - 99.999%) is very difficult and very expensive. One of the most expensive single points of failure to eliminate is the data center. In most cases, this effectively doubles the cost of your infrastructure, and the cost may be even greater than 2x, because you will often need to invest in technology to keep the servers in each data center in synch with each other.

Consider, however, the impact of adding a fully redundant data center. In our example above, the availability of our data center will redundant servers and ISPs was 94.3%. Adding a second data center with the necessary technology to make both centers work active-active (both data centers take traffic at the same time) would increase our availability to: 94.3% + (1-94.3%)*94.3% = 99.675%. Adding a second data center saved us 471 hours of downtime per year!

In this example, we assumed that each data center was an independent system, so a failure of a service in one data center would be a failure of the entire system in that data center. This is not always the case. For instance, if properly designed, a web server in one data center could connect to a database server in the other data center. In this case, the expected availability of the system would be higher that 99.675%. If you were able to design your site so that each service operated independent of the other services, then the availability in our example would increase from 99.675% to 99.888% (each service would have 3 redundant components, except the data center, which would have 1 redundant component).

These formulas are much easier to play with in Excel. Paste the following table into a spreadsheet, starting at cell A1:

Now that you have the basic concepts down, and the beginnings of a spreadsheet for calculating changes to our assumptions, you can focus on applying these theories to your unique situation. Start by breaking down your system, be it a web site, an accounting system, or a file server, into individual component services. For each service, determine the minimum number of units required for the system to work, and the expected availability of a unit.

Estimating availability can be a challenge. One method would be to look at historical data. If you don’t have access to good data, you can form an estimate based upon your standard operating parameters. For instance, if you release new code to your web server twice per month, and each release causes 2 hours of downtime, that would translate to 48 hours of downtime per year. If you expect to perform operating system maintenance once per quarter, at an estimated downtime of 2 hours per quarter, that would equal another 8 hours per year. If you also anticipate one hardware failure per year, and had a next business day warranty, that would translate to on average 41 hours of downtime per year (Friday outages get repaired on Monday. Saturday and Sunday outages get repaired on Tuesday). Adding these numbers up, we get: 48 + 8 + 41 = 98 hours of downtime per year, or an estimated 98.882% availability.

With a little work, you can estimate a realistic level of availability of your system. This is the cornerstone of creating realistic and attainable SLAs. These formulas can help IT negotiate SLAs with the business, and can help determine the comparative ROI of different solutions. For instance, let’s say you were trying to choose a web server solution, and you had two choices:

• Choice number 1 consists of 4 servers using cheap hardware with no internal redundancy. Each server costs $3,000. You estimate the availability of each server to be 75%.
• Choice number 2 consists of 2 servers using expensive hardware with redundant hard drives and power supplies. Each server costs $20,000. You estimate the availability of each server to be 99%.

You estimate the cost of downtime to be $500/hour, and you expect these servers to support your site load with a single server for the next 3 years, after which they will be replaced. Using the above numbers, Solution #1 has an expected availability of 99.6%, at a cost of $12,000. Solution #2 has an expected availability of 99.99% at a cost of $40,000. Solution #1 would experience 34 hours/year, or 102 hours over three years of downtime more than solution #2. Over three years, this extra downtime would cost $51,000. So by spending $28,000 upfront, you would get a three year ROI of 182%. Note that the model is only as good as your estimates. If the servers in solution #2 only had 95% availability, then their combined availability would be 99.75%, which would only provide 13 hours less downtime per year. In this case, you would only save $20,000 in downtime over three years for your $28,000 investment, so you would be better off with solution #1.

Designing and operating highly available systems is complicated work, but with a few simple formulas, it is possible to understand and predict their behavior at a macro level. This will allow you to make better decisions when choosing between multiple options, and give more realistic predictions when negotiating SLAs.

This letter got me thinking about all the supposedly strong security mechanisms employed by various online companies that I deal with that just make matters worse. The schwabplan.com PIN # confirmation is just one example. I used one of my common passwords expecting Schwab would treat it with the utmost care. To me, this would mean storing it in an encrypted, non-human readable form. Ideally, the password itself would not be stored at all. Instead, a hash of the password would be stored, and any time I entered my password, the hash of what I entered would be compared to the stored hash. This would protect my password from unscrupulous Schwab insiders, since statistics show that approximately 70% of security breaches occur from the inside.

Instead, not only does Schwab store the password, but they printed it out! Think for a second of all the hands my printed password went through. The printed letter hand to be put into an envelope. This may have been handled by a machine, but the machine still has an operator who could intercept the letter. The letter was then handled by a mail clerk at Schwab. From there, it passed through the Schwab postman, a postal clerk at Schwab’s local post office, at least one transport driver (probably more like 5) to get the letter from Ohio to my city, my local postal sorter, and my local postal delivery person. My wife brought the mail in, so that is one more hand.

That makes at least 8, and possibly 15-20 people who had physical possession of my carefully chosen password without my permission. The only thing keeping any of them from stealing my password, and ultimately my money, was a thin envelope. Since I was not expecting this letter to arrive, any one of them could have stolen the password, and I would have never known about it.

So why would Schwab send me my password? Since I had chosen it, in theory I know what it is. If they were worried that I was not the person who changed the password, they could have sent me a letter saying the password had changed on a specific date, and to call them if I was not the person who changed the password. Most likely, the reason they sent out my password was to cut down on their support calls. The letter includes this helpful instruction: “We recommend that you memorize this number and maintain this letter with your personal records.” In other words, we’ve written your password down for you, so you won’t call us. I’m surprised they didn’t print it on a sticker I could affix to my monitor!

So now I’m faced with a dilemma. I can’t change companies, because this is an employer sponsored program. I can’t change my password, because they’ll just mail it to me again! I could choose to not participate, but that would cost me thousands of dollars per year in lost benefits (tax breaks, employer matches, etc). The best I can do is “trust” that the system has not been compromised, or that if it is, Schwab will reimburse me if my account gets “hacked.”

There is a good lesson here for anyone designing password security for a website, or any other computer system. Password security is always a balance between security and usability, but there are some simple steps that can be used to make the security of your password system more “secure” without negatively impacting user experience:

1) Never, ever store user passwords in clear text. Either encrypt them, or better yet, use a 1-way hashing algorithm and store just the hash. This prevents a system admin or DBA from stealing the list of passwords.
2) Never use social security number as a username or password, and never store it clear text either. Did I mention that Schwab uses SS# as its username and I cannot change it? This again causes insider issues.
3) Do not log either the username or the password for successful or failed logins. Since Schwab uses my SS# as my username, a log of my username if I mistype my password would invalidate any encrypted storage of that number in their database.
4) Don’t ask for confidential information that will threaten your customers’ identities if stolen as a secondary password. For example, asking for mother’s maiden name, or city of birth, while seemingly innocuous, puts your customers at risk? How? Well if I can steal their name and mother’s maiden name, I can use that on other poorly designed sites to recover a password.
5) If a user forgets their password, validate some other piece of information before allowing them to reset the password. Preferably, ask them some transactional data that only they should know, and that changes frequently. For instance, ask them what the last stock they purchased, last widget they bought, last deposit they made was. This information changes faster than favorite color, first car, or pet’s name, so its value if stolen is reduced.
6) When a user forgets their password, never send the user the old password via snail mail, e-mail, fax, phone or carrier pigeon. Since you are not storing the password (see #1 above), you won’t have it to send anyway. Right? Instead, give the user a mechanism to change the password. For added security, send the user a confirmation to an alternate address that the password was changed. In other words, if you e-mail them a link for changing the password, send a snail mail confirmation letter. Or call the phone number on record to confirm. It is harder for someone to compromise two communication methods than it is one.

For the record, Schwabplan.com violated at least 4 of these precepts. I don’t know how they log failed password accounts, so I can’t speak to #3, but I don’t have high expectations. I expect to see a press release in the future that their security has been “compromised,” but they “take security seriously.”

Did I mention I am now a LifeLock affiliate? When financial companies treat our personal information so poorly, services like LifeLock may be the only answer. Check them out!

I should probably admit that I still really don’t have any idea who she is, and have never heard her music. The reason for my new found respect for Hannah is that two months ago, I changed my day job. I am now running technical operations for www.stubhub.com, a subsidiary of eBay.

If you’ve never heard of StubHub, click the banner on the left. StubHub is the leading secondary marketplace for concerts, sports events, and theater. If you want tickets to the World Series, the Super Bowl, or a sold-out concert, there is no better place than StubHub. And right now, Hannah Montana and Baseball Playoffs are the hot tickets.

People are going nuts for Hannah. As I write this, floor seats in Oakland, right in front of the stage are going for $1,500. There is also a luxury box with 20 tickets for over $11,000! This is the gotta have, must see, take me PLEEEAAASSSEEE!!!!! concert of the year. I love it!

I joined StubHub because it is truly my kind of company. First, it is a company with a solid foundation in the bricks-and-mortar world. People have been “scalping” tickets for a long time. By creating a neutral online marketplace, and backing it up with solid logistics and world class customer service, StubHub became the dominant player in the secondary ticket market. Second, it is a company that values its technology and its technologists. As such, it is a great place for an IT guy to work. Lastly, it is growing exponentially. The opportunity to design and build a highly-scalable, highly-available technical architecture was one I could not pass up.

Conceptually, I also love the free-market approach to ticket sales. StubHub does not take inventory of the tickets. We offer a secure place where fans can buy and sell tickets, and let the free market, not the ticket promoters set the market price. Hannah is a great example. The news is full of articles this week on parents complaining of being “gouged” by the ticket brokers. The Attorney General of Arkansas is investigating! What the people crying about the price seem to forget is the old laws of supply and demand. If they weren’t so desperate for the tickets, the price would fall.

I’ve neglected the blog lately, trying to get up to speed with the new gig. In the coming months, I have a bunch of articles planned based on the scalability challenges I am now facing. They should be worth the wait. In the mean time, visit StubHub, buy some tickets and go see Hannah. Let me know how you like the show.

PS> If you simply must see Hannah (in other words, you have a daughter), follow the StubHub advice for buying Hannah tickets. It may save you some money.

I was reminded of Cheshire’s article and the underlying principles recently when working on an international WAN design. What Cheshire noted was that light signals pass through fibre optics at roughly 66% of the speed of light, or 200*10^6 m/s. Regardless of the equipment or protocols you use, your data cannot exceed that theoretical limit. This limit equals the delay between when a packet is sent, and when it is received, aka latency.

In the US, we tend to focus on bandwidth and carrier technology when ordering circuits, completely ignoring latency. For instance, when choosing between cable and DSL for your house do you ever ask the carrier for its latency SLA? Maybe you should. Using a cable connection a ping to www.google.com in Mountain View, CA from my house (137 KM) yields an average ping time (aka round-trip time or RTT) of 73ms. The theoretical latency for this distance (round trip) is 1.37ms meaning my cable connection is roughly 50 times worse than the theoretical limit. No surprise that Comcast focuses on bandwidth and not latency in its marketing.

Cable and DSL circuits in the US are generally not business class and do not carry any service level agreement (SLA) on latency or availability. Businesses who use these circuits for business critical services do so at their peril. Business circuits such as Frame Relay and MPLS do generally include latency SLAs, but understanding the difference between the SLA and your actual experience can have a massive impact the performance of your network. For instance, let’s say a carrier advertises a 55ms round trip SLA in the US. This SLA equals the maximum latency between any two points of presence (POP) on their network.

The coast-to-coast distance in the US is roughly 5,000KM for a theoretical latency of 50ms, so a 55ms RTT SLA is pretty good. But that doesn’t mean packets on your network will only take 55ms to cross the country. When designing your WAN you must also account for the latency added by your network equipment and your servers, and the distance between the carrier’s POP and your offices. As a result, a well designed US WAN will still experience 75-80ms ping times. A poorly designed WAN can experience much worse times.

Now consider creating an international WAN. In this case, you typically will receive multiple SLAs from the carrier for different parts of the network. For instance, when designing an MPLS connection between California and the UK, the SLAs would be approximately 55ms within the US plus 95ms to cross the Atlantic Ocean plus 21ms to connect within the UK. Add the latency of your network and you get ping times of 175ms to 200ms.

At this point you are probably asking yourself “so what?” Two tenths of a second is no big deal. The answer is the impact of latency on TCP windowing. Transmission Control Protocol (TCP) has a flow control mechanism that senses latency and bandwidth between two hosts and determines the rates which data will be transferred. The TCP window is the amount a unacknowledged data a sender can transmit before waiting for a TCP ACK. As the latency increases, the TCP window shrinks, meaning the sender sends less data before waiting for an ACK. This helps reduce the amount of data that will need to be retransmitted in case a packet gets lost. Smaller windows equals more packets, and more packets equals more data because each packet carries the overhead of a 40 byte TCP/IP header regardless of if the payload is 1 byte or 1500 bytes.

The result is what I call the “Sandbag Problem.” Let’s say the two of us are trying to fill sandbags. My job is to scoop sand into a container and hand the full container to you (data). Your job is to empty the container into a sandbag and hand the empty container (ACK) back to me. Occasionally you drop the container so I have to fill it again (Retransmit). If we were standing next to each other, the time it takes for me to hand the container to you, have you empty it, and hand it back to me (latency) would be very small. Now imagine there is a 6′ wall between us, and I need to hand the container over to you.

The wall changes several aspects of our filling operation. First, the size of the container must be smaller because I cannot lift the same weight over my head that I can lift at waist level. Second, the time to complete one cycle would increase because it takes longer to lift the container 6′ than it does 3′. Third, you would drop more containers so retransmissions would increase. As the wall gets taller, the problem gets worse. If the wall were 10′ tall, we would be throwing containers instead of lifting them, so they would need to be even smaller. The containers would be traveling 20′ round trip instead of 12′ so the delay would increase 75%. And we would need to send a lot more containers to move the same amount of sand.

TCP works just like the sandbag problem. As distance increases, the TCP window shrinks, the time between transmission and acknowledgement increases, and the number of packets required to move the data grows. One reason for this is the effect of TCP congestion avoidance algorithms on the window size. The result is that the effective “speed” of the link decreases exponentially as the distance increases, regardless of bandwidth. RFC 1323 TCP Extensions for High Performance provides for mechanisms to deal with part of this problem. One method is to tune the TCP window on your hosts based upon a calculation of Bandwidth Delay Product (BDP). BDP = bandwidth x delay. Example: A 2Mb/s E1 link between California and the UK would have a BDP of 2.048Mb/s x 200ms = 51,200 Bytes. This is the ideal TCP window to fill the pipe so that the sender is not sitting idle waiting for ACK packets. Most hosts have a TCP Window default size of 64KB so, in this scenario, no adjustments would be needed. But, if the connection were a 45Mb/s DS3, then the BDP would be almost 1,100KB. In this scenario, TCP windows would need to be adjusted to use the available bandwidth at peak efficiency.

For most network applications, anything over 100ms latency is noticeable to your end users. Time sensitive applications such as VOIP or video teleconferencing suffer the worst experience when delay is introduced. Added to this is the impact of jitter. Jitter is the delay caused when packets travel alternative paths to the destination, and either arrive out of order, or with varying intervals between them. Applications such as e-mail that are bursty and not time sensitive do not feel the impact of latency to the same degree. How much of a problem is this for you today? One way to measure latency on your network is to use your carrier’s looking glass tools. A list of major looking glasses may be found at: http://www.nanog.org/lookingglass.html.

When designing for latency in a WAN it is important to first understand the applications on the network. After the applications have been profiled, steps can be taken to mitigate the impact of network delay. In part 2 of this article, we will discuss methods of designing for latency mitigation.

I’ve thrown together a little calculator for you to do some rudimentary math. Assuming an average of 30 days in a month, 24 hours in a day, 60 minutes in an hour, and 60 seconds in a minute. While the math is fairly straight-forward, it is by no means 100% accurate. Some months have less or more than 30 days, and on DST days, you get or lose an hour.

You should also be aware that while you are given some amount of transfer per month, this does not keep you from bursting above what the calculator shows. The calculator shows a “sustained” rate of data transfer. If you actually only use 1Mb/s of bandwidth, but you have a transfer allowance of 500GB/Month, you will be able to burst above the 1.5Mb/s sustained on occasion. 1-and-1, for instance, allows bursting up to 100Mb/s, but on their smallest VPS plan gives you 500GB/Month (roughly a T1/DS1 circuit sustained.)

Let me know if I’ve missed something.

-Jerry

Editors Note: Jerry Gilreath is our senior open systems consultant. He’s also the kind of guy who writes a JavaScript bandwidth calculator just for the heck of it. Jerry runs the excellent Gadget Workshop blog for everything expensive and geeky. Check it out.