$Id: pilc.jhtml,v 1.4 2004/04/21 16:53:44 nishida Exp $

PILC related docs


IETF PILC WG


RFCs


TCP Performance Implications of Network Path Asymmetry (rfc3449)
非対象ネットワークとTCPの関係について言及したもの
Downlinkが 10Mbpsで UPlinkが 5Mbpsで 1000 bytes data packetと 40 bytes ACKの を想定すると、非対象の ratioは 200/25 = 8になる。この場合、receiverが 8 packet に 1ackを返送する以上の頻度で ACKを転送すると、uplinkが混雑して転送性能が劣化 する。(TCPのdownlink性能が uplinkによって制約されてしまう)。 また RTTが長くなることにより、timeoutが生じる可能性がある。

UP stream linkが充分な queue size持っていない場合、ACKのいくつかがdropする。
ACKのdropには次の３つの問題がある。
  • TCPの転送のバースト性が増える
  • Cwndの増加速度が低下する。
  • Fast retransmitが機能しない可能性がある。

TCPをmodifyする解決法には次の様なものがある。
  • delayed ACKの頻度を変更する。->あまり推奨できない。
  • Large MSSを使用して、データに対するACKの割合を減らす。->PMTUDを利用する。
  • ACC(ACK Congestion Control)を利用する。(ACKにもECN bitをセットする)。ECNbitの立った、ACKを受信すると delayed ACKの頻度を変更する。
  • Window Prediction Mechanismを利用する。(receiver側で cwndを推測し、delayed ACKの頻度を計算する)
  • ACE(Acknowledgement based on Cwnd Estimation)を利用する。(WPMとほぼ同様)
  • TCP Sender Pacingを利用する。(maxburstを設定して burstを抑える)
  • TCP Byte Countingを利用する。->sender spacingなどとの併用が前提。
  • Backpressureを利用する。-> ACK Compressionを緩和する。
それ以外の解決方法
  • Header Compression
  • ACK Filitering
  • ACK Decimation (ACK用のキューを作ってdrop) -> AFほど controlできない。
  • ACK Reconstruction(新たにACKを作ってAFで空いたスペースを埋める) ->ちょっと力業。。
  • ACK Compaction and Companding(AFするときに削除したACKの情報等を追加する)
  • ACKs-first Scheduling


Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations (rfc3135)


End-to-end Performance Implications of Slow Links (rfc3150)
Category: Best Current Practice

低速(very low bit rate)のリンクで性能を向上させる手法について解説したもの。
  • Header Compression
    wirelessの場合、rfc1144がうまく機能しないのが問題。rohcに期待?
    time stamp optionは compressできないし、RTO estimationにあまり役に立たない。 (PAWSには効果はあるが、slow linkでは関係ない)
    rfc2507の利用を推奨。PPP deviceなら rfc2509を利用。
  • Payload Compression
    rfc2393の利用は場合によっては効果的
    (payloadが上位レベルで既に圧縮されている場合は役に立たない)
  • MTUの選択
    大きなMTUを選択すると、パケットの転送が200msec以上かかり DelACKがうまく 機能しなくなる。
    100-200msec以上のdelayは human-perceptibleである。
    small mtuはfast retransmit/fast recoveryが機能しやすい
    small mtuはqueueing delayが小さい。
    100-200msecの遅延が生じる様な大きなMTUは選択しない。
  • 輻輳制御とのInteraction


Advice to link designers on link Automatic Repeat reQuest (ARQ) (rfc3366)
Category: Best Current Practice

link layerで ARQを実装する場合の注意点について解説したもの。

ARQの利用には、適切なpersistenceを設定する必要がある。 低い persistency(2-5回程度で再送をあきらめる）を設定する場合、TCPのRTOに 与える影響が減少するので、パケットの複製の可能性が低くなる。 伝搬遅延の小さなリンクでは、トータルの転送時間が100msec程度に抑えられるならば １フレームに対して 10回程度の再送を試みても良いかもしれない。 通信経路は複数のリンクで構成されるので、１つのリンクで生じる最大遅延時間の 値には議論の余地がある。

Link outageをlink層で検出できるならば、link outage時に ARQの persistencyを 大きくすることにより、TCPを素早くlink outageから回復させることができるかも しれない。(TCPでは ACKの喪失はタイムアウトに繋がり、連続してACKが喪失すると、 RTOがbackoffする。) でも、再送のトラフィックが他のノードの通信に影響を 与える場合もあるので注意が必要。

packetのreorderingは、様々な悪影響があるのでlink層ではできるだけ reorderingを 避けるべきである。

Flowの性質に合わせて ARQの persistencyを変更することができれば効率が良いが、 困難が多い。


End-to-end Performance Implications of Links with Errors (rfc3155)
Category: Best Current Practice

BERの高いリンクにおいて、中継ノードによる特殊な処理を行わずに TCPの 性能を向上させる手法について解説したもの。
Slow Start/Congestion Avoidance、 Fast Retransmit/Fast Recoveryと SACKの導入を推奨している。

検討すべき技術としては、Limited Transmit、Delayed Duplicate ACKなどがある。 ECNをリンクエラーの notificationとして使うことはできない。ABCはACKを lossした場合に、burstinessを増加させるので現時点では推奨できない。
TCP以外のアプローチには、HTTP/1.1の利用などがある。TCP Control Block Interdependenceも有効かもしれない。


TCP over Second (2.5G) and Third (3G) Generation Wireless Networks (rfc3481)
Category: Best Current Practice

TCPを2.5G、3Gのネットワークで利用する場合のチューニング tipsをまとめたもの。
    2.5G,3Gネットワークの特徴
  • Latency: 通常 2,300misecから1sec
  • Data rates: uplink 1-20kbos/ downlink 1-40kbps (2.5G), uplink 64kbps /downlink 384kbps (3G)
    BDP: 1-5kbytes (2.5G) 8-50kbyes (3G)
    さらにData rateは環境によって（セル内の他のユーザの挙動など）大きく変化する。
  • Asymmetry: linkは非対象だが 3-6倍の範囲内なので大きな影響はない。
  • Delay Spikes: 様々な要因から突発的な delayがしばしば発生する。
    TCPでの対策
  • BDPに応じて Window Sizeをセットする。
  • Large Initial Windowを利用する。(mobile wireless deviceでは数セグメントしか送信しない通信が多い）
  • Limited Transmit (BDPが小さいので有効)
  • Large MTUを選択できる余地を与える
  • PMTUDを利用する。
  • SACKを利用する。
  • ECNを利用する。
  • Timestamps optionを利用する。(再送パケットでも RTTが計測できる。Eifelが利用できる。計測頻度を上げることにより spurious timeoutの可能性を減らせる)
    しかし同時に 12byteのoverheadがあることと、header compressionが機能しないなどの問題点がある。(rohcを利用する可能性はあるが。。)
  • Header Compressionをやめる。(rfc1144は lossyな環境では使ってはいけない)
    Open Issue
  • rohcの利用、AQMの利用、wireless levelでの再送など




I-Ds





back