How to test SD-WANs

A new Network World article, written by SD-WAN-Experts president and founder Steve Garson, discusses the need to test SD-WAN devices with your specific network conditions and impairments to make sure you’ve selected the best solution for your network when it experiences instability and/or congestion. “Whenever Continue reading How to test SD-WANs

How to Find Application Performance Problems

The main reason to use a WAN emulator is to test application performance.  But finding the problems are only the first half of the battle – the other half is fixing them.  The folks at Love My Tool (www.lovemytool.com), with Continue reading How to Find Application Performance Problems

Apposite’s Gluten-Free WAN Emulators

Today’s Wall Street Journal described how due to the popularity of gluten-free foods, food producers are stamping many of their products “gluten-free” even if like milk and yogurt, they never contained any of the grains that include gluten. (http://online.wsj.com/articles/how-we-eat-the-gluten-free-craze-is-it-healt hy-1403491041?KEYWORDS=gluten). Continue reading Apposite’s Gluten-Free WAN Emulators

The APP Test Series: Testing Skype Mobile Video Chat

Recently, my brother and I wanted to try mobile video chatting with our parents in Hawaii from our apartment in LA. Our dad has a Samsung Galaxy S, so we decided to call him with my brother’s Samsung Galaxy S3 Continue reading The APP Test Series: Testing Skype Mobile Video Chat

ネットワークの世界における遅延とは

[The following posting is by Kazuo Yokosuka of Rikei Corp., a reseller of Apposite’s products in Japan.] こんにちは。株式会社 理経の横須賀です。Apposite Technologies社WANエミュレータの販売担当をしております。今回は、前回の記事でも予告した通り、ネットワークの世界における遅延について記事を書きたいと思います。長い文章になりますが、どうぞお付き合い下さい。 お客様からApposite社WANエミュレータのお問い合わせを頂くときに、まず、ほとんどのお客様が「パケットに遅延をかけてみたいのですが…」というご要望をお持ちです。なぜか「パケットロスを再現したいです」「パケットの順序を入れ替えたいです」というお声は余り聞きません。日本のお客様にとって遅延はもっとも重要性のある検証項目のようです。 そもそも遅延とは何でしょうか?ネットワークの世界では、遅延とは、「あるデータのパケットが、クライントとサーバー間のネットワークを、『往復』するのにかかった時間」のことを言います。「往復」というところがポイントです。行きと帰りにかかった時間の合計時間なのです。エンジニアの方なら、しばしば端末への疎通をPingコマンドで確認すると思いますが、その時もRTT(round trip time)として、パケットの往復時間が、ミリ秒単位で表示されます。その時間は上りと下りの回線で発生した遅延の合計時間なので、上りと下りでそれぞれ何ミリ秒かかったかは、Pingではわかりません。(ちなみに、Apposite社のLinktropyとNetropyでは、この上りと下りの遅延をそれぞれ設定できます。) この遅延は、ネットワーク上にあるルータやスイッチが、パケットを処理し次のホップに転送するための時間の累積によって引き起こされている、と思われがちなのですが、WAN回線上では、遅延は主に端末間の物理的な距離が原因になります(ただし、端末間の物理的な距離が短い、LAN内なら、機器の処理による遅延はある程度影響が大きくなります。)。 よく知られているように、電磁波の速度は、「真空中では」光速と同じです。光の速度は非常に高速なので、惑星間の移動でも無い限り、私たちは通常生活において、光の速度を無視して生活しています。(隣町に光が届くのは、0.00…秒後だ、などとは考えませんよね。光の速度については後述します。)しかし、コンピュータプロセッシングの世界においては、その0.00…秒の遅延が重要になってきます。光がほぼ無限大に高速でも、大陸間の通信だけでなく、都市間、町と町の通信にも、その到達にかかる時間は影響を与えるのです。それでは、遅延について、改めて考えてみましょう。 図:Linktropyの操作画面。「Delay」が遅延を設定する項目です。「LAN A→LAN B」「LAN B→LAN A」で、それぞれ上りと下りの遅延を設定できます。Constant:常に一定の遅延を掛ける。Uniform:一様分布。最小値と最大値を設定し、その間の数値の遅延をランダムに発生させ、ジッターを発生させる。 Normal:正規分布。平均値や標準偏差の大小を設定。 遅延を構成する幾つかの要素 あるアプリケーションがデータを送受信する際、遅延の原因となる要素は複数あります。OSI参照モデルの一番上の層から考えてみましょう。 1.アプリケーションまたはホストによる遅延 送信側のアプリケーションが、パケットをTCP/IP層に手渡す時に発生する遅延、また、反対側にある受信側のアプリケーションがパケットを受信・処理し、応答を返す時に発生する遅延、これらをまとめて「アプリケーション遅延」と呼びます。比較的単純なPing/ICMPエコーリクエストなどのアプリケーションでは、このアプリケーションによる遅延は、マイクロ秒単位になります。一秒間で数万件の株式の取引が行われる、コンピュータによる「高頻度取引(HFT)」の世界でも無い限り(ナノ秒単位の遅延が問題になるそうです)、アプリケーション遅延は無視されることが多いようです。もちろん、アプリケーションが複雑になってくると、アプリケーション遅延もより大きくなっていきます。 2.伝送遅延 私達がデータのパケットについて考える時、つい、ケーブル上を伝わっていく一つの箱のようなものをイメージしがちですが、実際には「1」と「0」の数字の長い羅列で、それは1つずつ転送される必要があります。その羅列の一番初めのビットが、ポートから送出され、最後のビットが転送されるまでの時間を「伝送遅延」または「シリアライゼーション遅延」といいます。この遅延は、パケットのサイズが大きい時、さらにネットワークの帯域幅が狭いときに大きくなります。例えば、64バイトのパケットを1Gbpsのネットワーク上で送信するときは、0.5マイクロ秒ほどの時間しかかからず、ほぼ無視できます。1500バイトのパケットでも0.12ミリ秒しかかかりません。ところが、1500バイトのパケットを712kbpsのDSL回線で送ろうとすると、なんと伝送遅延だけで16ミリ秒かかります。伝送遅延に関して言えば、私たちはブロードバンドの恩恵を十分に受けていると言えますね。 3.伝搬遅延 この「伝搬遅延」は、WAN回線上の遅延の主な原因です。ケーブルで結ばれたある地点から、ある地点にパケットを送った時にかかる、物理的な時間のことを指しています。一般的に光の速さは真空中で約30万キロメートル/秒となりますが、光ファイバーを通ると、その速度は約20万キロメートル/秒まで落ちます。例えば、アメリカだと、ロサンゼルスとニューヨークは約5000キロメートル離れています。結果、光ファイバーを通るパケットは、伝搬遅延だけで往復約50ミリ秒かかります(5000km÷20万km毎秒×2)。日本で考えてみると、東京-大阪間が約500キロメートルなので、伝搬遅延は往復約5ミリ秒となります。(こう考えると、日本国内の通信では、アメリカほど遅延が問題にならないのかもしれませんね。)もちろん、これは理論上の話です。ロサンゼルス-ニューヨーク間、東京-大阪間で敷設されているケーブルの長さは、施設内の引き回しなどを考慮すると、もっと長いはずです。 この伝搬遅延が大きいと、いくら100Mbpsや1Gbps等の広帯域の回線を家庭や企業で契約しても、TCP/IP通信では、データ転送速度がそれほど出なくなります(UDP通信はこの影響を受けません。なので、このUDP通信をベースにした、WAN高速化装置も市場にいくつかあります)。TCP/IP通信は、原則的に、データが一つ一つ宛先に届いたかどうか確認してから次のデータを送るからです。衛星を利用したIP通信などでは、特にこれは顕著です(地球局A→衛星→地球局B→衛星→地球局Aで、約500msecかかります。)。こればっかりは、いくらブロードバンド化を進めても、どうしようもない問題です。 4.キューイングまたは輻輳遅延 Continue reading ネットワークの世界における遅延とは

A Beginner’s Guide to WAN Acceleration, Part II

Original Article can be found here: http://www.smallnetbuilder.com Breaking Down the Box Since there are two separate problems – lack of bandwidth and the ability to use the available bandwidth, there are two different sets of optimizations included in any full-featured Continue reading A Beginner’s Guide to WAN Acceleration, Part II

A Beginner’s Guide to WAN Acceleration, Part I

Original Article can be found here: http://www.smallnetbuilder.com Introduction WAN acceleration products that optimize application performance have historically been the domain of huge enterprises connecting far-flung operations. But that is starting to change. Even small companies are becoming more dispersed, with Continue reading A Beginner’s Guide to WAN Acceleration, Part I

Winnie’s Pregnant

As we were catching our breath after racquetball a few days ago, I asked Steve, “So, how’s the construction business lately?”  We usually talk about business or politics while cooling down, and politics seemed especially fraught lately. He sipped his Continue reading Winnie’s Pregnant