Latency, Bandwidth, Throughput နှင့် BDP

နားလည်ထားရမယ့် အချက်

Bandwidth, latency နဲ့ throughput ကို လူတွေ အပြန်အလှန် အစားထိုးပြီး သုံးကြပေမယ့် အဓိပ္ပာယ် သုံးမျိုး ကွဲပြားတယ်။ Bandwidth ဆိုတာ capacity — link တစ်ခုက သယ်နိုင်တဲ့ တစ်စက္ကန့် bit အများဆုံး။ Latency ဆိုတာ delay — bit တစ်ခု အရောက်သွားဖို့ ဘယ်လောက်ကြာလဲ။ Throughput ကတော့ သင် တကယ် ရလိုက်တဲ့ ပမာဏ ဖြစ်ပြီး နှစ်ခုလုံးအပြင် ကြားထဲက အခြားအရာအားလုံးကပါ ကန့်သတ်ထားတယ်။

Latency ဟာ ကိန်းဂဏန်း တစ်ခုတည်း မဟုတ်ဘူး — အရာလေးခုရဲ့ ပေါင်းလဒ် ဖြစ်တယ်။ Propagation delay ဆိုတာ အကွာအဝေးကို medium ထဲက signal အမြန်နှုန်းနဲ့ စားလိုက်တာ — ရူပဗေဒ ဖြစ်ပြီး သင် ဘာဝယ်ဝယ် လျှော့ချလို့ မရဘူး။ New York ကနေ London ဟာ တစ်လမ်းသွား မီလီစက္ကန့် လေးဆယ်ခန့် ဖြစ်ပြီး အမြဲ ဒီအတိုင်းပဲ ဖြစ်နေမယ်။ Transmission delay ဆိုတာ packet size ကို link rate နဲ့ စားလိုက်တာ — bit တွေကို ကြိုးပေါ် တင်ဖို့ ကြာချိန် — ပြီးတော့ ဒါက bandwidth တိုးရင် တိုးသလို ကောင်းလာတဲ့ တစ်ခုတည်းသော အစိတ်အပိုင်း ဖြစ်တယ်။ Queuing delay ဆိုတာ router ရဲ့ buffer ထဲမှာ တခြား traffic နောက်ကနေ စောင့်ရတဲ့ အချိန်ဖြစ်ပြီး၊ အပြောင်းအလဲ အများဆုံး အစိတ်အပိုင်း ဖြစ်တယ် — congestion ကို တကယ် ခံစားရတာ ဒါပါပဲ။ Processing delay ကတော့ router ကိုယ်တိုင်ရဲ့ lookup အလုပ်ဖြစ်ပြီး ယနေ့ခေတ်မှာ သိပ် မသိသာတော့ဘူး။

ဒီ ခွဲခြမ်းစိတ်ဖြာမှုက လူတွေ အယူအဆနဲ့ အဆန့်ကျင်ဆုံး ထင်ရတဲ့ ရလဒ်ကို ရှင်းပြပေးတယ် — link တစ်ခုကို 100 Mbps ကနေ 1 Gbps တင်လိုက်တာဟာ transfer တစ်ခုရဲ့ ပြီးဆုံးချိန်ကို ဘာမှနီးပါး မပြောင်းလဲစေတတ်ဘူး။ Propagation က လွှမ်းမိုးနေရင် သင်ဟာ သေးတဲ့ ကိန်းကို မြှောက်လိုက်ပြီး ကြီးတဲ့ ကိန်းကို ထားခဲ့လိုက်တာပါ။

Bandwidth-delay product နဲ့ဆိုရင် ပိုပြီး ထက်မြက်လာတယ်။ BDP ဆိုတာ bandwidth နဲ့ round-trip time ကို မြှောက်လိုက်တာဖြစ်ပြီး၊ လမ်းကြားမှာ ရှိနေတဲ့ byte အရေအတွက် — ပို့ပြီးသား၊ acknowledge မရသေးတဲ့ — ကို တိုင်းတာတယ်။ Window အသေတစ်ခု သုံးနေတဲ့ sender တစ်ခုဟာ pipe ဘယ်လောက် ကျယ်ကျယ် window ကို RTT နဲ့ စားလိုက်တဲ့ ပမာဏထက် ဘယ်တော့မှ မကျော်နိုင်ဘူး။ 100 Mbps, 80 ms transatlantic link တစ်ခုမှာ BDP ဟာ megabyte တစ်ခုနီးပါး ရှိလို့ classic 64 KB window တစ်ခုက TCP flow တစ်ခုကို Mbps အနည်းငယ်မှာ ကန့်သတ်ထားလိုက်တယ်။ Bandwidth ဆယ်ဆ တိုးလိုက်တာက အဲဒီကိန်းကို လုံးဝ မပြောင်းစေဘူး။ Pipe က ပိုကျယ်သွားတယ်၊ ဒါပေမယ့် ကန့်သတ်ချက်က သူ့ရဲ့ အလျားပါ။

THE FOUR COMPONENTS OF LATENCY AND THE PIPE ANALOGY
---------------------------------------------------
ONE PACKET, START TO FINISH (not to scale)

sender                                                receiver
  |-proc-|--queuing---|--transmission--|--propagation--->|
     ^         ^              ^                ^
     |         |              |                |
  router    waiting in     size / link     distance / speed
  lookup    the buffer     rate            of signal
  (tiny)    (varies a lot) ^^^^^^^^^^^     (pure physics,
                           ONLY this one     you cannot
                           shrinks when      buy your way
                           you buy more      out of it)
                           bandwidth


PIPE ANALOGY

  bandwidth = how WIDE the pipe is
  latency   = how LONG the pipe is
  BDP       = how much water is INSIDE it right now

  narrow + short  |==|                   tiny BDP, 64KB is plenty
  narrow + long   |==================|   moderate BDP
  wide   + short  |####|                 tiny BDP
  wide   + long   |##################|   HUGE BDP, needs a big
                                         window or you idle

  Making the pipe wider does not make it shorter. A transfer
  limited by the LENGTH gains nothing from more WIDTH.

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Service တစ်ခုကို region တစ်ခုကနေ တစ်ခုဆီ ရွှေ့လိုက်တဲ့အခါ စက္ကန့် နှစ်ဆယ်ကြာခဲ့တဲ့ file transfer တွေဟာ လေးမိနစ် ကြာသွားတယ် — provider က 1 Gbps လို့ ကျိန်ဆိုနေတဲ့ link ပေါ်မှာပါ။ ဘယ်သူမှ link ကို မယုံကြည်ကြဘူး။ များသောအားဖြင့် link က ဘာမှ မဖြစ်ပါဘူး။

Ticket မဖွင့်ခင် ဂဏန်းတွက်ကြည့်ပါ။ Ping နဲ့ round-trip time ကို တိုင်းပါ၊ bandwidth-delay product ကို တွက်ပါ၊ ပြီးရင် တကယ် သုံးနေတဲ့ TCP window နဲ့ ယှဉ်ကြည့်ပါ။ BDP က ကိုးမီဂါဘိုက်ဖြစ်ပြီး window က 64 KB ဆိုရင် flow တစ်ခုဟာ Mbps ခြောက်ခုလောက်ထက် ပိုကောင်းလို့ ဘယ်တော့မှ မရနိုင်ဘူး — link ကို ဘယ်လောက် သတ်မှတ်ထားလဲဆိုတာ အရေးမကြီးတော့ဘူး၊ sender ဟာ ပို့နေတာထက် acknowledgement စောင့်နေတာနဲ့ အချိန်အားလုံးနီးပါး ကုန်နေလို့ပါ။

ဖြေရှင်းနည်း နှစ်ခုက အဲဒီကနေ တိုက်ရိုက် ထွက်လာတယ်။ Window scaling ကို ဖွင့်ပြီး kernel ကို buffer တွေ auto-tune လုပ်ခိုင်းပါ — ဒါက flow တစ်ခုအတွက် အမြင့်ဆုံးကို တင်ပေးတယ်။ ဒါမှမဟုတ် flow အများကြီးကို တစ်ပြိုင်နက် run ပါ — multi-threaded download tool တွေနဲ့ object-storage client တွေဟာ link ရှည်တွေပေါ်မှာ ဘာကြောင့် ဒီလောက် ပိုမြန်သလဲဆိုတာ ဒါကြောင့်ပါပဲ — flow တစ်ခုစီက သူ့ကိုယ်ပိုင် window ရပြီး window တွေ ပေါင်းလိုက်လို့ ရတယ်။

တူညီတဲ့ ကျိုးကြောင်းဆင်ခြင်မှုက CDN တွေ အလုပ်ဖြစ်ရတဲ့ အကြောင်းရင်းပါပဲ။ CDN က bandwidth ပိုမပေးဘူး — အကွာအဝေးကို တိုစေတယ်၊ ဒါက propagation delay ကို ကျုံ့စေပြီး၊ အားလုံးကို စားနေတဲ့ RTT ကို ကျုံ့စေတယ်။ ပြီးတော့ ဒါက chatty protocol တွေ ဘာကြောင့် link ရှည်တွေပေါ်မှာ ဒီလောက် နာကျင်စေလဲ ဆိုတာလည်း ရှင်းပြတယ် — round trip တစ်ခု တိုးတိုင်း byte ဘယ်လောက်နည်းနည်း ရွှေ့ရွှေ့ RTT အပြည့် ကုန်ကျတယ်။

• Bandwidth က capacity, latency က delay, throughput က ရလဒ်
• Bandwidth ဝယ်ရင် transmission delay တစ်ခုတည်းသာ ကောင်းလာတယ်
• BDP = bandwidth x RTT — လမ်းကြားက data ပမာဏနဲ့ လိုအပ်တဲ့ window

အတူတူ စမ်းရေးကြည့်မယ်

# Bandwidth is capacity (bits per second).
# Latency is delay (seconds).
# Throughput is what you actually get, and on a single TCP flow it is
# capped by  window_size / RTT  -- bandwidth never enters that formula.

LINKS = [
    # name, bandwidth in Mbps, round-trip time in milliseconds
    ("LAN, same rack",        1000,   0.5),
    ("City fibre",             100,   10.0),
    ("Transatlantic",          100,   80.0),
    ("Satellite (GEO)",         50,  600.0),
    ("Transatlantic, 10x pipe", 1000,  80.0),
]

DEFAULT_WINDOW_KB = 64   # the classic un-tuned TCP receive window


def bdp_bytes(mbps, rtt_ms):
    bits = mbps * 1_000_000 * (rtt_ms / 1000.0)
    return bits / 8.0


print("link                      Mbps    RTT      BDP   win64KB gives")
print("-------------------------------------------------------------")
for name, mbps, rtt in LINKS:
    bdp = bdp_bytes(mbps, rtt)
    # Throughput actually achievable with a fixed window:
    achievable_bps = (DEFAULT_WINDOW_KB * 1024 * 8) / (rtt / 1000.0)
    achievable_mbps = achievable_bps / 1_000_000
    capped = min(achievable_mbps, mbps)
    print(name.ljust(25) + str(mbps).rjust(5) +
          ("%.1fms" % rtt).rjust(9) +
          ("%.0fKB" % (bdp / 1024)).rjust(9) +
          ("%.1f Mbps" % capped).rjust(13))

print("")
# The window you would NEED to actually fill each pipe.
print("window required to saturate each link:")
for name, mbps, rtt in LINKS:
    need_kb = bdp_bytes(mbps, rtt) / 1024
    print("  " + name.ljust(25) + ("%.0f KB" % need_kb).rjust(9))

print("")
# The headline result: 10x the bandwidth, identical throughput.
print("'Transatlantic' and 'Transatlantic, 10x pipe' differ by 10x in")
print("bandwidth and deliver the SAME throughput with a 64KB window.")
print("Latency, not capacity, is the binding constraint there.")

# One transfer, decomposed. Propagation is distance; transmission is
# size/rate; queuing and processing are the router's fault.
SIZE_KB = 1500
prop_ms = 40.0                                   # one way, transatlantic
trans_ms = (SIZE_KB * 1024 * 8) / (100 * 1_000_000) * 1000
queue_ms = 3.0
proc_ms = 0.2
print("")
print("one 1500KB transfer over the 100Mbps/80ms link:")
print("  propagation  %.2f ms" % prop_ms)
print("  transmission %.2f ms" % trans_ms)
print("  queuing      %.2f ms" % queue_ms)
print("  processing   %.2f ms" % proc_ms)
print("  total        %.2f ms" % (prop_ms + trans_ms + queue_ms + proc_ms))

link                      Mbps    RTT      BDP   win64KB gives
-------------------------------------------------------------
LAN, same rack            1000    0.5ms     61KB  1000.0 Mbps
City fibre                 100   10.0ms    122KB    52.4 Mbps
Transatlantic              100   80.0ms    977KB     6.6 Mbps
Satellite (GEO)             50  600.0ms   3662KB     0.9 Mbps
Transatlantic, 10x pipe   1000   80.0ms   9766KB     6.6 Mbps

window required to saturate each link:
  LAN, same rack               61 KB
  City fibre                  122 KB
  Transatlantic               977 KB
  Satellite (GEO)            3662 KB
  Transatlantic, 10x pipe    9766 KB

'Transatlantic' and 'Transatlantic, 10x pipe' differ by 10x in
bandwidth and deliver the SAME throughput with a 64KB window.
Latency, not capacity, is the binding constraint there.

one 1500KB transfer over the 100Mbps/80ms link:
  propagation  40.00 ms
  transmission 122.88 ms
  queuing      3.00 ms
  processing   0.20 ms
  total        166.08 ms

RFC 7323 - TCP Extensions for High Performance — Computer Networking