$Id: pilc.jhtml,v 1.2 2003/08/23 17:10:08 nishida Exp $

PILC related docs


IETF PILC WG


RFCs


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は選択しない。
  • 輻輳制御


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 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