第 5 章 結論 67
5.2 今後の課題
第3章で示した最適直列化法とFGTCPを組み合わせる方法について，クライアントとサーバ の帯域幅が異なる場合においても，インキャストを発生させることなく，高いスループットを達 成できる可能性があるため，最適直列化法を拡張して，性能を確認する予定である．
第4章で示したクライアントによる再送要求方法について，再送要求を送信するか否かを判断 する閾値を最適化することで，さらにスループットを向上できる可能性があるため，閾値がスルー プットやネガティブ影響率に及ぼす影響を明らかにし，その調整方法を検討する予定である．
また，第3章と第4章のそれぞれの提案法に共通して，実機環境に実装して，実際のデータセ ンター環境下における性能評価を行う予定である．
謝辞
本研究の全過程を通じて，豊かな知識と経験をもってご指導ご鞭撻を賜りました岡山大学大学 院自然科学研究科横平徳美教授に深甚なる感謝の意を表します．
また，本研究を推進するにあたり，ご激励，ご支援賜りました岡山大学大学院自然科学研究科 杉山裕二教授並びに野上保之准教授に感謝致します．
さらに，岡山大学大学院自然科学研究科電子情報システム工学専攻博士前期課程および同産業 創成工学専攻博士後期課程においてお世話になりました森川良孝岡山大学名誉教授，古賀隆治岡 山大学名誉教授，秦正治岡山大学名誉教授，並びに岡山大学大学院自然科学研究科舩曵信生教授，
田野哲教授，東京農工大学山井成良教授に感謝致します．
さらに，研究の細部に渡り御指導頂いた岡山大学大学院自然科学研究科福島行信助教に感謝致 します．
また，企業に在籍しながら大学院に進学することについて，親身に相談に応じていただき，後 押ししてくださいました，株式会社日本総合研究所執行役員赤澤清様，並びに同開発推進部門開 発企画部次長由井成和様，同開発推進部門開発企画部部長代理金子雄介様に厚くお礼申し上げま す．そして，大学院進学後，大学院での研究活動と企業での執務の両立についてご配慮賜りまし た株式会社日本総合研究所開発推進部門セキュリティ統括室長砂田浩行様，および，同社関係各 位にお礼申し上げます．
最後に，本研究の途中において，実験，データ整理にご協力をいただきました岡山大学工学部 通信ネットワーク工学科の卒業生，在学諸氏にお礼申し上げます．
参考文献
[1] Apache Hadoop.http://hadoop.apache.org/.
[2] S. Shepler, M. Eisler and D. Noveck, “Network File System (NFS) Version 4 Minor Version 1 Protocol,”RFC 5661, January 2010.
[3] J. Postel, “Transmission Control Protocol,”RFC 793, September 1981.
[4] V. Paxson, M. Allman, J. Chu and M. Sargent, “Computing TCP’s Retransmission Timer,”
RFC 6298, June 2011.
[5] Y. Ren, Y. Zhao, K. Dou and J. Li, “A survey on TCP Incast in data center networks,”
International Journal of Communication systems, Vol. 27, pp. 1160–1172, July 2012.
[6] Y. Zhang and N. Ansari, “On Architecture Design, Congestion Notification, TCP Incast and Power Consumption in Data Centers,”IEEE Communications Surveys and Tutorials, Vol. 15, No. 1, pp. 39–64, First Quarter 2013.
[7] A. Phanishayee, E. Krevat, V. Vasudevan, D. G. Andersen, G. R. Ganger, G. A. Gibson and S. Seshan, “Measurement and Analysis of TCP Throughput Collapse in Cluster-based Storage Systems,”The 6th USEUNIX Conference on File and Storage Technologies (FAST 2008), pp. 1–13, February 2008.
[8] Y. Chen, R. Griffith, J. Liu, R. H. Katz and A. D. Joseph, “Understanding TCP Incast Throughput Collapse in Datacenter Networks,”ACM WREN 2009, pp. 73–82, August 2009.
[9] H. Wu, Z. Feng, C. Guo and Y. Zhang, “ICTCP: Incast Congestion Control for TCP in Data Center Networks,”ACM CoNEXT 2010, November 2010.
[10] H. Wu, Z. Feng, C. Guo and Y. Zhang, “ICTCP: Incast Congestion Control for TCP in Data-Center Networks,”IEEE/ACM Transactions on Networking, Vol. 21, Issue 2, pp. 345–
358, April 2013.
[11] J. Hwang, J. Yoo and N. Choi, “IA-TCP: A Rate Based Incast-Avoidance Algorithm for TCP in Data Center Networks,” IEEE ICC 2012 - Communication QoS, Reliability and Modeling Symposium, pp. 1292–1296, June 2012.
[12] W. Richard Stevens, “TCP/IP Illustrated, Volume 1 The Protocols,” Addison-Wesley, 1994.
[13] M. Alizadeh, A. Greenberg, D. A. Maltz, J. Padhye, P. Patel, B. Prabhakar, S. Sengupta, and M. Sridharan, “Data Center TCP (DCTCP),” SIGCOMM 2010, pp. 63–74, August 2010.
[14] Y. Zhang and N. Ansari, “On Mitigating TCP Incast in Data Center Networks,” IEEE INFOCOM 2011, pp. 51–55, April 2011.
[15] J. Zhang, F. Ren, L. Tang and C. Lin, “Taming TCP Incast Throughput Collapse in Data Center Networks,”2013 21st IEEE International Conference on Network Protocols (ICNP), pp. 1–10, October 2013.
[16] W. Bai, K. Chen, H. Wu, W. Lan and Y. Zhao, “PAC: Taming TCP Incast Congestion Using Proactive ACK Control,” 2014 22nd IEEE International Conference on Network Protocols (ICNP), pp. 385–396, October 2014.
[17] J. Zhang, F. Ren, X. Yue, R. Shu and C. Lin, “Sharing Bandwidth by Allocating Switch Buffer in Data Center Networks,” IEEE Journal on Selected Areas in Communications, Vol. 32, No. 1, pp. 39-51, January 2014.
[18] C. Deng, X. Wang and S. Lu, “MIP: Minimizing the Idle Period of Data Transmission in Data Center Networks,”IEEE ICC 2014 - Communication QoS, Reliability and Modeling Symposium, pp. 1179–1184, June 2014.
[19] J. Zhang, F. Ren, L. Tang ad C. Lin, “Modeling and Solving TCP Incast Problem in Data Center Networks,”IEEE Transactions on Parallel and Distributed systems, Vol. 26, No. 2, pp. 478–491, February 2015.
[20] A. S.-W. Tam, K. Xi, Y. Xi and H. J. Chao, “Preventing TCP Incast Throughput Col-lapse at the Initiation, Continuation, and Termination,”Proceedings of the 2012 IEEE 20th International Workshop on Quality of Service (IWQoS ’12), Article No. 29, June 2012.
[21] E. Kervat, V. Vasudevan, A. Phanishayee, D. G. Andersen, G. R. Ganger, G. A. Gibson and S. Seshan, “On Application-level Approaches to Avoiding TCP Throughput Collapse in Cluster-based Storage Systems,”Proceedings of the 2nd international workshop on Petascale data storage (PDSW ’07), pp. 1–4, November 2007.
[22] M. Podlesny and C. Williamson, “An Application-Level Solution for the TCP-incast Prob-lem in Data Center Networks,” IEEE 19th International Workshop on Quality of Service (IWQoS) 2011, pp. 1–3, June 2011.
[23] M. Podlesny and C. Williamson, “Solving the TCP-incast Problem with Application-Level Scheduling,”IEEE 20th International Symposium on Modeling, Analysis and Simulation of Computer Telecommunication Systems, pp. 99–106, August 2012.
[24] V. Vasudevan, A. Phanishayee, H. Shah, E. Krevat, D. G. Andersen, G. R. Ganger, G. A. Gibson and B. Mueller, “Safe and Effective Fine-grained TCP Retransmissions for Datacenter Communication,”SIGCOMM 2009, pp. 303–314, August 2009.
[25] S. Osada, K. Kajita, Y. Fukushima and T. Yokohira, “TCP Incast Avoidance Based on Connection Serialization in Data Center Networks,” The 19th Asia-Pacific Conference on Communications 2013 (APCC 2013), pp. 120–125, August 2013.
[26] K. Kajita, S. Osada, Y. Fukushima and T. Yokohira, “Improvement of a TCP Incast Avoid-ance Method for Data Center Networks,” International Conference on ICT Convergence 2013 (ICTC 2013), pp. 459–464, October 2013.
[27] S. Osada, R. Miyayama, Y. Fukushima and T. Yokohira, “TCP Incast Avoidance Based on Connection Serialization in Data Center Networks,”International Journal of Computer Networks & Communications (IJCNC), Vol. 8, No. 4, pp. 83–102, July 2016.
[28] The Network Simulator – ns-2. http://www.isi.edu/nsnam/ns/.
[29] M. Allman, V. Paxson and W. Stevens, “TCP Congestion Control,”RFC 2581, April 1999.
[30] M. Allman, V. Paxson and E. Blanton, “The TCP Congestion Control,”RFC 5681, Septem-ber 2009.
[31] T. Henderson, S. Floyd, A. Gurtov and Y. Nishida, “The NewReno Modification to TCP’s Fast Recovery Algorithm,”RFC 6582, April 2012.
[32] Gary R. Wright and W. Richard Stevens, “TCP/IP Illustrated, Volume 2 The Implemen-tation,” Addison-Wesley, 1995.
[33] D. Borman, B. Braden, V. Jacobson and R. Scheffenegger, “TCP Extensions for High Performance,”RFC 7323, April 2012.
[34] D. Nagle, D. Serenyi and A. Matthews, “The Panasas ActiveScale Storage Cluster: De-livering Scalable High Bandwidth Storage,” IEEE/ACM Supercomputing 2004, pp. 53–62, November 2004.
[35] Ryo Miyayama, Shigeyuki Osada, Yukinobu Fukushima and Tokumi Yokohira, “Optimiza-tion of Maximum Timeout Value in TCP with a Fine-grained Timer for Data Center Net-works,” International Conference on ICT Convergence 2014 (ICTC 2014), pp. 433–437, October 2014.
付録 A TCP におけるパケット送受信処理
TCP（Transmission Control Protocol）は，インターネットのような低信頼ネットワーク上で，
高信頼のエンド間バイトストリーム通信を行うためのトランスポート層プロトコルである．
TCPは，コネクション指向で設計されており，データ通信の開始にあたり，送信元から送信先 に対して接続要求（SYNパケット）を送信する．SYNパケットには，データの順序性を保証する ために，送信元が設定したシーケンス番号の初期値が格納されている．それを受信した送信先は，
接続要求を承諾する確認応答（ACKパケット）を返送する．このACKには，送信先が設定する シーケンス番号の初期値も一緒に格納されるため，SYN-ACKパケットと呼ぶ．このSYN-ACK パケットを受信した送信元は，接続要求が承諾されたと認識し，それと合わせて，送信先が設定し たシーケンス番号の初期値を確認したことを示すACKパケットを送信先に返送し，その後，デー タの送信が開始される．コネクション確立時には，必ずこのSYNとSYN-ACKとACKの各パ ケットが送信され，この一連の流れのことを，three-wayハンドシェイクと呼ぶ．
TCPでは，ネットワークの輻輳を回避するために，ネットワークに流入するデータ量をスライ ディング・ウィンドウを使って制御する．スライディング・ウィンドウには，送信先で制御を行 うための広告ウィンドウと，送信元で制御を行うための輻輳ウィンドウの2種類がある．前者は，
一般に，送信先のノードが持つ受信バッファの容量が設定され，後者は，後述するように，送信 元の輻輳制御アルゴリズムに従って設定される．送信元は，2つのウィンドウの最小値を超えない 範囲で，確認応答を待つことなく，連続してデータを送信することができるが，ウィンドウを超 えてデータを送信することはできない．
また，TCPは，シーケンス番号と再送タイマを使うことで，パケット消失を検知し，消失した パケットを再送する機能を有する．TCPは，パケット送信時に，再送タイマをセットする．再送 タイマがタイムアウトするまでに対応するパケットの確認応答が返送されてこなければ，そのパ ケットが消失したと判断して再送を行う．この再送タイマに設定する値のことを，再送タイムア ウト値（RTO）と呼び，RTTの統計値を使って以下のように計算して求める．
SRTT = αSRTT+ (1−α)R (A.1)
RTTVAR = βRTTVAR+ (1−β)|SRTT−R| (A.2)
RTO = αSRTT+ 4×RTTVAR (A.3)
ここで，SRTTは平滑化されたRTT（Smoothed Round-Trip-Time）で，RTTVARはRTTの標 準偏差である．また，αとβは，それぞれ，7/8と3/4が設定される．なお，Rは，RTO計算時に 計測したRTTである．このとき，計算によって求めたRTOが過度に小さく設定されることがない ように，最小値（RTOmin）を事前に設定しておき，その値未満になるときは，RTOにRTOmin を代入する．
再送タイムアウトが繰り返されるときは，輻輳が長期間継続している可能性を鑑みて，RTOは 以下のように計算する．
RTO = 2×RTO (A.4)
このように指数的にRTOを増加させることを指数バックオフと呼ぶ．
TCPは，前述の再送方法の他に，高速再送（Fast Retransmission）と呼ばれる，タイマを使わ ない再送方法を持っている．送信先は，送信元から順序違いのシーケンス番号を持つパケットを 受信すると，前回返送した確認応答番号を持つACKパケットを複製して，返送する．これを重複 ACKと呼び，送信元はこれを連続して3個受信すると，途中のパケットが消失したことにより，
順序違いのパケット到着が発生したと認識して，確認応答が返送されていない最小のシーケンス 番号を持つパケットを再送する．重複ACKが生成されるような，パケット消失数が少ないとき は，高速再送により素早く再送を行うことができる．一方で，重複ACKが生成されないような深 刻なパケット消失が発生しているときは，再送タイマのタイムアウトよって再送される．
輻輳によるパケット消失を防ぐために，TCPは，前述したように，輻輳制御アルゴリズムを持っ ている．輻輳制御アルゴリズムは，スロースタートと輻輳回避の2つのアルゴリズムから構成さ れる．スロースタートは，three-wayハンドシェイクの直後や，後述する再送タイムアウト後に実 行されるアルゴリズムで，RTT毎に輻輳ウィンドウが2倍になる．一方，輻輳回避は，輻輳ウィ ンドウの値が，後述するスロースタート閾値（ssthreshold）よりも大きいときに実行されるアル ゴリズムで，RTT毎に輻輳ウィンドウが1MSSずつ増加する．ssthresholdは，再送が発生しない 限り，十分に大きい値が設定されているため，輻輳やパケット消失がないネットワークでは，輻 輳ウィンドウはRTT毎に指数的に増加し，その結果，送信元がすぐに大量のデータを送信可能に なる．しかし，再送が発生するような場合，ssthresholdは，輻輳ウィンドウを過度に大きな値に しないように，これまでに実行した再送の方法によって，以下のように制限する．
再送タイムアウトによる再送を行った場合，送信元は，輻輳状態が深刻であると捉えて， ssthresh-oldに現時点の輻輳ウィンドウの1/2を設定し，また，即時にパケット送信量を抑えるために，輻 輳ウィンドウの値を1MSSに設定する．一方，高速再送による再送を行った場合，送信元は，輻 輳状態が警備だと捉えて，ssthresholdの値は変更せずに，輻輳ウィンドウの値をssthresholdに設 定する．