2024-01-17-19 JANOG53 参加レポート

Day1

15:30 海外で日本のやり方が通用しないの、なぁぜなぁぜ？　東南アジアでのインターネットインフラを構築の実例から、グローバルでのオペレータ交流を考える

BBIX 立松さん : 資料

ケーブリングやばいよ

• 海外はケーブリングがとてもやばいぞ !

品質とスピード

• 日本の品質は海外案件に適用できない
  • 海外はスピード優先で、企画・設計・構築をやる必要がある
• レンタカーはドライバー付きじゃないと、クルマを貸し出してくれない
  • 「今日は走れるクルマが少ないんだよー」「!?」
  • 車両ナンバーの末尾で、走行できる日が規制されている
• DC に持ち込みは Quarantine (検疫) で 1 日必要
  • immunity test のために必要 : 電源に影響を及ぼさないかのチェックのため
  • 今回については、何もやってない (DC で 1 日放置)

税関で製品が止められる件

輸出の該非判定が必要、通関のために書類がいろいろ求められる。

• Cisco はオンラインで書類を発行できたりする
• 中古機材は持ち込むのが難しい
  • 新品はメーカーから書類を入手したり、ノウハウがあったり
  • 香港も厳しいらしい

NTT-Data 冨樫さん : 資料

ジャカルタで JKT-IX を立ち上げた話。

• IX 単体で儲けるのではなく、コンテンツプロバイダなどのターゲット顧客を DC に誘致して、DC を拡販する

相互接続交渉が難航した話

日本人が交渉して 2-3 ヶ月接続できなかったのが、交渉先のボードメンバーと友達を交渉担当者にアサインすると 1 週間で妥結された。。

プライジング

2017 当時の IX マーケットだと、IX は $0

• 費用を取ろうとすると、めっちゃ怒られた

シェア No.1 を取って、無料と高速プランに分けて課金できるようになった。

インドネシアの要求品質

同時複数ダウン時以外はトラブルシュートしない、通知しない。

利用者から要求がない品質は追わない。

他のメンバーからの問い合わせや、全体に影響する問題は妥協せず対応する。

特殊局が手掛けるIN地域研究室の紹介「インターネット業界の未来を創る技術者育成」

NTT 特殊局

光ファイバー・クロージャー・果物 (!?)

技術研究に適したコンピュータ・ネットワークを提供する。

パワーワード集

苦行センター

うちのメールサーバーにはアメリカ人が住んでいた

• 最近は中国かロシアからのホームステイが多い

IN 地域 NW (インチキ NW)

イン地域研究室

• サーバ・ネットワークを自由に触れる環境

霞が関 曼荼羅

• PPT にすべての要素を詰め込んで書き込まれたもの
• 参考 : 環境省の作ったパワポ資料がある意味すごいと話題

僕がいなくなったらふすまが開くようになったらしい

• ISP・検証用の機材を木造の 2 階自室に置いていたら、家が傾いていた
• 実家 -> 東京に引っ越した

「NTT 東日本に就職すれば、ダークファイバーを使い放題だよね」

• そう思っていた時代も僕にもありました

つぶらなひとみで「光ファイバ利用申請書類」を提出すると・・・

ブートストラップ問題

(登さん) ネットワークの初学者が学ぶための、書籍が古くなっていて入りづらくなってきていて、口伝になってしまっている

質疑応答 : NTT は金持ちだから成長しなかった ?

お金が自由に使えることで、不利になることがある。お金に制限があることで、知恵と工夫をする余地が生まれる。

• Google : インチキサーバで企業

• Amazon : Sun のサーバが高すぎたので、クラウドを作った

もの好き同士の連携が少なくなっているのでは。

Day2

400G時代の相互接続 〜100G-LR1って検討されてますか？〜

資料

100G-LR4 が高いので、100G-LR1 ってどう ? というセッション。

比較

規格	変調方式	波長数	FEC	ブレークアウト	メリット	デメリット
100G-LR4	NRZ : 2 値	25G x 4 波長	任意	?	使用実績が長い	コストが高い
100G-LR1	PAM4 : 4 値	100G x 1 波長	必須	400G-PLR4 から可能	IC 部の微細化でコスト低減されそう 波長数が少ないため、HW コンポーネント数が低減 -> MTBF に好影響	リンクアップが遅い

データセンターネットワークでの輻輳対策どうしてる？

In-cast congestion

• any src to 1 dest
• 受信側で tail drop
• 対処が難しい
• 今回の発表のメイン対象

Fabric congestion

• 不均衡なトラフィック分散

Lossy

• TCP 再送でカバー

Lossless

• RDMA などでロスレスにする

対処策

• 専用 NW
  • 専用構成が乱立
• 輻輳対策 HW
  • コストが妥当なのか ?
• バッファチューニング
  • これは実施していない

輻輳制御の手法

• Deep Buffer
• ECN , PFC
• DCTC
• H-TCP , CUBIC , BBR

Deep Buffer

GB 単位の HBM 大容量メモリでバースト トラフィックを吸収する

HoLB (Head of Line Blocking) 対策の VoQ

VoQ アーキテクチャと Buffer Broat (バッファによる遅延)

Loss-Based TCP 輻輳制御アルゴリズムだとバッファを埋め尽くすまで止まらない

• AQM で先行してドロップさせる

ECN (Explicit Congestion Notification)

• 受信側がフィードバックのために、送信側に Notification して、送信を抑制する

PFC (Priority-based Flow Control)

• Traffic Class のキューから PAUSE フレームを送信する

Hadoop

In-cast Congestion が起きやすい Hadoop を検証ターゲットとした。

TeraSort

• Hadoop に標準搭載されたベンチマーク

予想に反した検証結果

• Deep Buffer のジョブ完了時間が、Shallow Buffer よりも長い
  • Deep Buffer はドロップが抑えられているが、時間が長かった
• 負荷が高くても Shallow (短い) Buffer のほうが、ジョブ完了時間が短かった
• PFC のみ有効だと、InDiscards が増加し、OutDiscards は発生しない

予想通りだった検証結果

• ECN を設定すると Drop がほぼ抑えられた
• Deep Buffer よりも速く完了した

今後のアクション

• Deep Buffer は必要ないかも