Sunday, August 31, 2008

TCP နဲ႔ Bandwidth


TCP Protocol ရဲ့ အဓိက ရည္ရြယ္ခ်က္က ကြန္ပ်ဴတာႏွစ္လုံး ဆက္သြယ္ၾကတဲ့အခါ ယံုၾကည္စိတ္ခ်ရေအာင္ျဖစ္ပါတယ္။
လမ္းခုလပ္မွာ အခ်က္အလက္ေတြ ေပ်ာက္ရွပ်က္စီးသြားရင္ေတာင္မွာ TCP က ျပန္ျပီးပုိ႔ေပးတာမ်ဳိးေပါ့။ Network ထဲမွာ bandwidth တုိ႔၊ delay တုိ႔ ေျပာင္းသြားတာကုိ မူတည္ျပီး အခ်က္အလက္ပုိ႔ေပးတဲ့ႏွုန္း အေႏွးအျမန္ကုိ TCP ကအလုိအေလ်ာက္ ထိန္းသိမ္းေပးပါတယ္။ congestion control လုိ႔ေခၚပါတယ္။
TCP မွာသုံးတဲ့ congestion control မွာ နည္းစံနစ္မ်ဳိးစုံပါ၀င္ပါတယ္။ ဥပမာေျပာရရင္
- ေနဂယ္ရဲ့ algorithm
- selective acknowledgement
- fast retransmit
- window flow control
- slow start
စတာေတြျဖစ္ပါတယ္။

အဲဒါေတြထဲက TCP Window နဲ႔ Bandwidth အေၾကာင္းေျပာသြားပါမယ္။ အဓိကမွတ္ထားေစခ်င္တာကေတာ့ congestion control ဆုိတာ Application တစ္ခုက အခ်က္အလက္ပုိ႔တဲ့ အေႏွးအျမန္ႏွုန္းကုိ TCP က အလုိအေလ်ာက္ ထိန္းသိမ္းေပးတဲ့ နည္းစံနစ္ေတြျဖစ္တယ္ဆုိတဲ့ အခ်က္ပါ။

Host0 နဲ႔ Host1 ဥပမာကုိဘဲ ဆက္သုံးၾကတာေပါ့။ Host0 ကအခ်က္အလက္ ပုိ႔ေပးတဲ့ ကြန္ပ်ဴတာ၊ Host1 က အခ်က္အလက္ လက္ခံမဲ့ ကြန္ပ်ဴတာ ေပါ့။
Host0 က Host1 ဆီကုိ TCP အသုံးျပဳျပီး အခ်က္အလက္ပုိ႔ေပးတဲ့အခါ လက္ခံတဲ့ကြန္ပ်ဴတာ Host1 က ရရွိတဲ့အေၾကာင္းျပန္ေျပာေပးရပါတယ္။ ဒါကုိ acknowledgment လုိ႔ေခၚပါတယ္။ Host0 က acknowledgment ျပန္မရခင္ Host1 ဆီကုိ အခ်က္အလက္ ဘယ္ေလာက္မ်ားမ်ား ပုိ႔ေပးႏုိင္တယ္ဆုိတာကုိ window size လုိ႔ေခၚပါတယ္။ Window size ဟာ TCP Packet ရဲ့ေခါင္းစီး (header) မွာပါတဲ့ field တစ္ခုျဖစ္ျပီး ၁၆-ဘစ္ အရြယ္အစား ရွိပါတယ္။ ဒါေၾကာင့္ အၾကီးဆုံး TCP Window size ဟာ ၂^၁၆ = ၆၄ ကီလုိဘုိက္ ျဖစ္ပါတယ္။ RFC-793 စာမ်က္ႏွာ ၁၄၊ အပုိင္း ၃.၁ မွာ TCP ေခါင္းစီးရဲ့အခ်က္အလက္သုိေလွာင္ပုံ (format) ကုိေလ့လာႏုိင္ပါတယ္။

Window size ရဲ့ အၾကီးဆုံးတန္ဖုိးဟာ ၆၄ ကီလုိဘုိက္ ျဖစ္တယ္ဆုိတာကုိ တနည္းေျပာရရင္ - Host0 က Host1 ဆီကုိ acknowledgment မရခင္မွာ အခ်က္အလက္ ၆၄ ကီလုိဘုိက္ထက္ ပုိျပီးပုံလုိ႔မရဘူးလုိ႔ ဆုိလုိပါတယ္။ Host0 နဲ႔ Host1 ၾကားက Network ရဲ့ latency က ၁၀ မီလီစကၠန္႔ဆုိပါစုိ႔။ Host0 က Host1 ကုိ packet တစ္ခုပုိ႔ျပီး၊ acknowledgment ျပန္ရမဲ့အခ်ိန္ကုိ တုိင္းတာခ်င္ရင္ latency ကုိ ၂ ဆပြားျပီးတြက္ခ်က္ရပါတယ္။ ဘာေၾကာင့္လဲဆုိေတာ့ Host0 ကေန Host1 ကုိ packet ပုိ႔ဖုိ႔ၾကာတာက ၁၀ မီလီစကၠန္႔၊ Host1 ကေန Host0 ကုိ acknowledgment ပုိ႔ေပးဖုိ႔ ၾကာတာက ၁၀ မီလီစကၠန္႔ - စုစုေပါင္း အသြားအျပန္ၾကာခ်ိန္ ၂၀ မီလီစကၠန္႔ျဖစ္ပါတယ္။ ဒါကုိ အသြားအျပန္ၾကာခ်ိန္ (RTT - Round Trip Time) လုိ႔ေခၚျပီး TCP နဲ႔ပတ္သက္တဲ့စာအုပ္ေတြ၊ Network နဲ႔ပတ္သက္တဲ့ စာအုပ္ေတြမွာ မၾကာခဏ ေတြ႔ရပါလိမ့္မယ္။

ကၽြန္ေတာ္တုိ႔ေဆြးေႏြးေနတဲ့ ဥပမာမွာ - Window size က ၆၄ ကီလုိဘုိက္၊ RTT က ၂၀ မီလီစကၠန္႔ ဆုိေတာ့ Host0 က Host1 ကုိ TCP သုံးျပီး အျမန္ဆုံးပုိ႔ေပးႏုိင္တဲ့ ႏွုန္းကုိ ေအာက္မွာေပးတဲ့ Formula နဲ႔တြက္မယ္ဆုိရင္

[ Window size / RTT = TCP ရဲ့အျမန္ႏွုန္း ]
၆၄ ကီလုိဘုိက္ / ၂၀ မီလီစကၠန္႔ = ၂.၅၆ မက္ဂါဘစ္ ပါ စကၠန္႔ (တစ္စကၠန္႔ကုိ ၂.၅၆ မက္ဂါဘစ္) ျဖစ္ပါတယ္။

ကြန္ပ်ဴတာ Network ေတြမွာ ၁၀၀ မက္ဂါဘစ္၊ ၁ ဂစ္ဂါဘစ္ အျမန္ႏွုန္းကုိ ေနရာတုိင္းလုိလုိမွာ ေတြ႔ေနရျပီျဖစ္ပါတယ္။ TCP Window size ရဲ့ကန္႔သတ္ခ်က္ေၾကာင့္ Network ရဲ့ အျမန္ႏွုန္းအတုိင္း အခ်က္အလက္ေတြကုိ မပုံ႔ႏုိင္ဘဲ့ ေႏွးေကြးေနတာ ျဖစ္တတ္ပါတယ္။ ၆၄ ကီလုိဘုိက္ window size ဆုိတာ ၁၉၈၁ ခုႏွစ္က သတ္မွတ္ခဲ့တဲ့ စံနစ္ျဖစ္တဲ့အတြက္ေၾကာင့္ ဒီေန႔ေခတ္မွာ အသုံးမတဲ့ေတာ့ပါဘူး။ ဒါေပမယ္လည္း TCP ေခါင္းစီးရဲ့ အခ်က္အလက္သုိေလွာင္ပုံကုိ ျပန္ျပင္ဖုိ႔ဆုိတာလည္း သိပ္မလြယ္ပါဘူး။ ဒီျပသနာကုိေျဖရွင္းဖုိ႔အတြက္ TCP Window Scaling Option ဆုိတာကုိ ၁၉၉၂ ခုႏွစ္မွာ တီထြင္ခဲ့ပါတယ္။ traceroute ကုိေရးခဲ့တဲ့ Van Jacobson က ေခါင္းေဆာင္ခဲ့တာျဖစ္ျပီး၊ RFC-1323 စာမ်က္ႏွာ ၇၊ အပုိင္း ၂ မွာအေသးစိတ္ဖတ္ၾကည့္ႏုိင္ပါတယ္။

Window Scaling Option ရဲ့အလုပ္လုပ္ပုံကေတာ့ TCP window size ကုိ အဆပြားႏုိင္တဲ့ ဂဏန္းတစ္ခုကုိ Host0 နဲ႔ Host1 တုိ႔သေဘာတူၾကဖုိ႔ျဖစ္ပါတယ္။ Window scaling factor ကုိ TCP ေခါင္းစီးရဲ့ option field ကုိအသုံးျပဳပါတယ္။ ဆုိပါစုိ႔ TCP Window size field က ၃၂ ကီလုိဘုိက္ျဖစ္ျပီး window scale factor က ၁၀၀၀ ျဖစ္ရင္ - ကြန္ပ်ဴတာက ပုိ႔ေပးႏုိင္တဲ့ စုစုေပါင္းအရြယ္အစားက ၃၂ မက္ဂါဘုိက္ျဖစ္ပါမယ္။

တမ်ဳိးလွည့္ျပီးစဥ္းစာၾကည့္ရေအာင္။ Host0 ကေန Host1 ကုိ 1Gpbs ႏွုန္းတဲ့ TCP ကုိသုံးျပီးပုိ႔ခ်င္ရင္ Window size ဘယ္ေလာက္ထားသင့္သလဲ။ RTT က ၂၀ မီလီစကၠန္႔ဘဲ ဆုိပါစုိ႔။ အရင္သုံးတဲ့ formula ကုိ နည္းနည္းေျပာင္းလုိက္တာပါဘဲ။

[ TCP အျမန္ႏွုန္း * RTT = Window Size ]
၁ ဂစ္ဂါဘစ္ ပါ စကၠန္႔ * ၂၀ မီလီစကၠန္႔ = ၂.၅ မက္ဂါဘုိက္ - TCP Window size ကုိသုံးရပါမယ္။

ျပန္ေျပာရရင္ ၂၀ မီလီစကၠန္႔ အသြားအျပန္ၾကာခ်ိန္ (RTT - Round Trip Time) ရွိတဲ့ Network မွာ TCP ကုိသုံးျပီး 1Gbps အျမန္ႏွုန္းနဲ႔ပုိ႔ခ်င္ရင္ 2.5 MBytes TCP Window size ကုိ သုံးရပါမယ္။

စာၾကြင္း -
၁၊ Operating Systems အားလုံးလုိလုိရဲ့ Default window size က 64KBytes ျဖစ္ပါတယ္။
၂၊ IPERF ဆုိတဲ့ free software tool ကုိသုံးျပီး ကိုယ့္ Network ရဲ့ TCP အျမန္ႏွုန္း ဘယ္ေလာက္ရွိတယ္ဆုိတာကုိ တုိင္းတာႏုိင္ပါတယ္။
၃၊ Window scaling option ကုိသုံးျပီး OS ရဲ့ 64KBytes default limit ကုိ program မွာျပင္လုိ႔ရပါတယ္။ C ကုိသုံးထားတဲ့ ဥပမာကုိၾကည့္ၾကည့္ပါ။ setsockopt() function ကုိသံုးတာျဖစ္ပါတယ္။


/* An example of client code that sets the TCP window size */

int window_size = 128 * 1024; /* 128 kilobytes */
sock = socket(AF_INET, SOCK_STREAM, 0);
/* These setsockopt()s must happen before the connect() */
setsockopt(sock, SOL_SOCKET, SO_SNDBUF,
(char *) &window_size, sizeof(window_size));
setsockopt(sock, SOL_SOCKET, SO_RCVBUF,
(char *) &window_size, sizeof(window_size));
connect(sock, (struct sockaddr *) &address, sizeof(address));



/* An example of server code that sets the TCP window size */
int window_size = 128 * 1024; /* 128 kilobytes */
sock = socket(AF_INET, SOCK_STREAM, 0);
/* These setsockopt()s must happen before the accept() */
setsockopt(sock, SOL_SOCKET, SO_SNDBUF,
(char *) &window_size, sizeof(window_size));
setsockopt(sock, SOL_SOCKET, SO_RCVBUF,
(char *) &window_size, sizeof(window_size));
listen(sock, 5);
accept(sock, NULL, NULL);

Saturday, August 30, 2008

2008 US Open Diary - Aug 30


US Open Tennis ျပဳိင္ပြဲက်င္းပတဲ့ National Tennis Center နဲ႔ ကၽြန္ေတာ့အိမ္နဲ႔က ၂ မုိင္ေလာက္သာေ၀းပါတယ္။ ကားေမာင္းသြားရင္ ၅ မိနစ္ခန္႔ၾကာျပီး၊ လမ္းေရွာက္သြားရင္ေတာ့ ၂၀ မိနစ္ေလာက္ ၾကာပါတယ္။ ျပဳိင္ပြဲမစခင္ ၁ ပတ္အလုိ (ၾသဂုတ္လ ၁၈ ရက္ေန႔က ၂၂ ရက္ေန႔အထိ) မွာ အားကာသမားေတြ ေလ့က်င့္တာကုိ ပုိက္ဆံမေပးဘဲ သြားၾကည့္လုိ႔ ရပါတယ္။
အဲဒီအပတ္မွာဘဲ လက္ေရစစ္ျပဳိင္ပြဲေတြကုိလည္း ၾကည့္လုိ႔ရပါတယ္။

US Open မွာ အမ်ဳိးသား ၁၂၈ ေယာက္၊ အမ်ဳိးသမီး ၁၂၈ ေယာက္ ပါ၀င္ယွဥ္ျပဳိင္ၾကျပီး၊ ၁၄ ရက္ၾကာက်င္းပတာျဖစ္ပါတယ္။
ဒီ ၁၂၈ ေယာက္ထဲက ၁၆ ေယာက္ကုိ လက္ရည္စမ္းပြဲက ေရြးပါတယ္။ လက္ရည္စမ္းပြဲမွာ ၁၂၈ ေယာက္ပါ၀င္ျပီး၊ ၄ ရက္ၾကာ က်င္းပပါတယ္။ National Tennis Center မွာ တင္းနစ္ကြင္း ၂၀ ေက်ာ္ရွိျပီး၊ ျပဳိင္ပြဲကုိ ၁ရ ကြင္းေပၚမွာ ကစားပါတယ္။ ကြင္းအၾကီးၾကီး ၃ ပါတယ္။
၁၊ Arthur Ashe Stadium က အၾကီးဆုံးျဖစ္ျပီး ဖုိင္နယ္ပြဲေတြကုိ အဲဒီမွာဘဲ ကစားပါတယ္
၂၊ Louis Armstrong Stadium က ဒုတိယ အၾကီးဆုံးျဖစ္ပါတယ္
၃၊ Grand Stand က တတိယ အၾကီးဆုံး ျဖစ္ပါတယ္
က်န္တဲ့ ၁၄ ကြင္းကေတာ့ သိပ္ မတိမ္းမယိမ္းပါဘဲ။

လက္မွတ္မွာ (အရမ္းေစ်းၾကီးတဲ့ လက္မွတ္ေတြကလြဲလုိ႔)
၁၊ ေန႔လက္မွတ္ (မနက္ ၁၁ နာရီကစလုိ႔ ကုိယ္ၾကဳိက္သေလာက္ အ၀ၾကည့္ခြင္႔ရွိတယ္)
၂၊ ညလက္မွတ္ (ည ၆ နာရီကစလုိ႔ ကုိယ္ၾကဳိက္သေလာက္ အ၀ၾကည့္ခြင္႔ရွိတယ္)
၃၊ Ground Pass (Arthur Ashe Stadium ကုိ ၀င္ခြင့္မရတာကလြဲလုိ႔၊ ေန႔လက္မွတ္နဲ႔ဆင္တူပါတယ္)

အၾကီးဆုံးကြင္းျဖစ္တဲ့ Ashe Stadium မွာေတာ့ ခုံနံပါတ္ပါျပီး၊ က်န္တဲ့ကြင္းေတြမွာေတာ့ ဦးရာလူ ၾကိဳက္တဲ့ေနရာမွာ ထုိင္လုိ႔ ရပါတယ္။

လြန္ခဲ့တဲ့ ၁ နာရီေက်ာ္ေက်ာ္ကဘဲ Andy Roddick (အေမရိကန္)က Ernests Gulbis (လတ္ဗီးယား) ကုိ ေလးပြဲ အၾကိတ္အနယ္ကစားျပီး ႏုိင္သြားတဲ့ပြဲကုိ ၾကည့္ျပီးျပန္လာခဲ့ပါတယ္။ ပြဲျပီးခ်ိန္မွာ ေဒသစံေတာ္ခ်ိန္ မနက္ ၁ နာရီခြဲရွိေနပါျပီ။ ေသာၾကာေန႔ညဆုိေတာ့ ကြင္းမွာ လူေတာ္ေတာ္စီပါတယ္။

ေနာက္ေန႔မွ ၾကည့္ျပီးတဲ့ ပြဲေတြထဲက ေကာင္းႏုိးရာရာေတြ ေရးသြားပါမယ္။

လာမဲ့ အဂၤေန႔နဲ႔၊ ဗုဒၶဟူးေန႔ ေတြအတြက္ ေန႔လက္မွတ္၀ယ္လုိ႔ရခဲ့ပါတယ္။ ျပီးခဲ့တဲ့ တနလၤာနဲ႔၊ ေသာၾကာည ေတြမွာ ရုံးက သူငယ္ခ်င္း မိတ္ေဆြေတြနဲ႔ သြားၾကည့္းျဖစ္ခဲ့ပါတယ္။


Friday, August 22, 2008

2008 US Open Diary - Aug 21



Current World No.1

Rafael Nadal (Spanish)



Richard Gasquet (French)




Jo-Wilfried Tsonga (French)



David Nalbandian (Argentinean)

ေနဂယ္ ရဲ့ Algorithm


ဂၽြန္ေနဂယ္က ၁၉၈၄ ခုႏွစ္ မွာေရးခဲ့တဲ့ Algorithm ျဖစ္ျပီး၊ RFC-896 မွာ အသးစိတ္ဖတ္ၾကည့္ႏုိင္ပါတယ္။ TCP/IP Network တစ္ခုမွာ packet ေသးေသးေလးေတြ သြားေနတာကုိ သေဘာမက်လုိ႔ ေရးခဲ့တာပါ။ TCP Packet တစ္ခုမွာ ပုိ႔ခ်င္တဲ့ Data ဘယ္ေလာက္ရွိရွိ ေခါင္းစီးအခ်က္အလက္ (Header) က ၄၀ Bytes ေနရာယူပါတယ္။ Telnet လုိ Program မ်ဳိးမွာ Data က ၁ byte သာပါျပီး၊ ေခါင္းစီးက ၄၀ bytes ေနရာယူထားပါတယ္။ ေစ်းထဲက မက်ီးသီး ၅ က်ပ္သား၀ယ္တာ သတင္းစာ တစ္ေစာင္လုံးနဲ႔ ထုပ္ေပးလုိက္သလုိျဖစ္တာေပါ့။ ဒီ TCP Packet ေတြ Network ေပၚမွာသြားေတာ့ ဆင္ဖုိးထက္၊ ခၽြန္းဖုိးၾကီးဆုိသလုိ Header အခ်က္အလက္ေတြက Data ထက္ အဆ ၄၀ ပုိယူသလုိျဖစ္တာေၾကာင့္ Bandwidth အလဟသ ျဖစ္ရပါတယ္။ ၁၉၈၄ ခုႏွစ္ကဆုိ Bandwidth က နည္းကလည္းနည္း ေစ်းကလည္းၾကီးဆုိေတာ့ ဒီျပသနာကုိ ေျဖရွင္းဖုိ႔ဆုိတာ ေတာ္ေတာ္အေရးၾကီးတယ္လုိ႔ဆုိရပါမယ္။ (ဒီျပသနာကုိ Tinygram Problem လုိ႔ေခၚပါတယ္။)

ေနဂယ္ ရဲ့ Algorithm အလုပ္လုပ္ပုံကေတာ့ ပုိ႔စရာရွိတဲ့ အခ်က္အလက္ေတြကုိ ခ်က္ခ်င္းမပုိ႔ေသးဘဲေစာင့္ေနျပီး - အေတာ္အသင့္ မ်ားလာျပီဆုိမွ packet ကုိပုိ႔ေပးမယ္ဆုိျပီး ျပင္လုိက္တာျဖစ္ပါတယ္။ မဂၤလာဒုံကုိေျပးတဲ့ ၅၁ ကား ဆူးေလမွတ္တုိင္မွာ လူေစာင့္သလုိေပါ့။ ရုံးဆင္းခ်ိန္ဆုိရင္ လူျပည့္ဖုိ႔သိပ္ၾကာၾကာမေစာင့္ရဘဲ ခ်က္ခ်င္းထြက္ႏုိင္တယ္၊ ညဥ့္နက္လာရင္ေတာ့ ကားတစီးျပည့္ဖုိ႔ ေတာ္ေတာ္ ေစာင့္ရပါတယ္။ (အခု ၅၁ ကားဆက္ေျပးေသးလားဆုိတာေတာ့ မေျပာတပ္ဖူး။) ကားတစီးမွာ လူဘယ္ေလာက္ဆန္႔တယ္ဆုိတာ အကန္႔အသတ္ရွိသလုိ Packet တစ္ခုမွာ အခ်က္အလက္ ဘယ္ေလာက္ရွိတယ္ဆုိတာကုိ MSS (Maximum Segment Size) နဲ႔သတ္မွတ္ထားပါတယ္။ MSS ကေတာ့ Network Card ရဲ့ MTU (Maximum Transfer Unit) ျဖစ္ျပီး Ethernet မွာဆုိရင္ေတာ့ ၁၅၀၀ bytes ရွိပါတယ္။

TCP ပုိ႔ေဆာင္ေရးစနစ္ဆုိတာ ယုံၾကည္စိတ္ခ်ရတဲ့စနစ္ျဖစ္ပါတယ္။ ကြန္ပ်ဴတာႏွစ္လုံး TCP ကုိအသုံးျပဳျပီး ဆက္သြယ္တယ္ဆုိရင္ လမ္းမွာ အခ်က္အလက္ အေျပာက္အရွ မရွိရေအာင္ TCP ကတာ၀န္ယူပါတယ္။ TCP ကုိသုံးျပီး ဆက္သြယ္ေနတဲ့ကြန္ပ်ဴတာ ၂ ခုုကုိ Host1 နဲ႔ Host2 လုိ႔ေခၚမယ္ဆုိပါစုိ႔။ လက္ခံရရွိတဲ့ကြန္ပ်ဴတာ (Host2) က Packet တစ္ခုရတုိင္း အသိအမွတ္ျပဳတဲ့အေၾကာင္း Packet တစ္ခုကုိ ျပန္ျပီး မူလကြန္ပ်ဴတာ (Host1) ဆီကုိပုိ႔ေပးရပါတယ္။ အသိအမွတ္ျပဳတဲ့ packet ကုိ acknowledgment packet (အတိုေကာက္ ack) လုိ႔ေခၚပါတယ္။ Host1 က packet တစ္ခုပုိ႔ျပီးတုိင္း Host2 ဆီက ack ကုိေစာင့္ပါတယ္။ Ack မရေသးရင္ Host1 က ေနာက္ထပ္ပုိ႔စရာရွိတဲ့ အခ်က္အလက္ေတြကုိ ဆက္မပုိ႔ဘဲ ေစာင့္ေနပါတယ္။ Ack မရတာ ေတာ္ေတာ္ၾကာသြားရင္ Host1 က ပထမပုိ႔လုိက္တဲ့ packet လမ္းမွာ ေပ်ာက္သြားျပီလုိ႔ ယူဆျပီး အဲဒီ packet ကုိ ထပ္ပုိ႔ေပးပါတယ္။ ဒါကုိ Retransmission လုိ႔ေခၚပါတယ္။


Packet တစ္ခုပုိ႔တုိင္း ack တစ္ခုရဖုိ႔ေစာင့္ရတယ္ဆုိတာ (one to one acknowledgment လုိ႔ေခၚပါတယ္) လက္ေတြ႔မွာ အရမ္းေႏွးျပီး၊ ack ေတြအရမ္းမ်ားလုိ႔ bandwidth အလဟသ ျဖစ္ရပါတယ္။ ဒီကေန႔အသုံးျပဳတဲ့ TCP ရဲ့ acknowledgment စံနစ္မွာေတာ့ one-to-one ထက္ပုိေကာင္းတဲ့ sliding window စံနစ္ကုိသုံးပါတယ္။ Host1, Host2 ဥပမာနဲ႔ ျပန္ေျပာပါမယ္။ Host1 နဲ႔ Host2 ၾကားမွာ အသိအမွတ္မျပဳေသးခင္မွာ အခ်က္အလက္ ဘယ္ေလာက္မ်ားမ်ားပုိ႔ႏုိင္တယ္ဆုိတာကုိ window size လုိ႔ေခၚပါတယ္။ Window size က ကြန္ပ်ဴတာ ဘယ္ေလာက္အလုပ္ရွုပ္တယ္ဆုိတာေပၚမွာ မူတည္းျပီး အနည္းအမ်ား ေျပာင္းလဲတပ္တာေၾကာင့္ dynamic window size လုိ႔ေခၚပါတယ္။ Host1 နဲ႔ Host2 အခ်က္အလက္ေတြ မပုိ႔ေပးခင္မွာ window size ဘယ္ေလာက္ရွိတဲ့အေၾကာင္း အခ်င္းခ်င္း သတင္းဖလွယ္ရပါတယ္။ Host2 က Host1 ကုိ "ငါ့ရဲ့ window size ကေတာ့ ၄၅၀၀" လုိ႔ေျပာတယ္ဆုိပါစုိ႔။ (၄၅၀၀ ကုိ Host2 ရဲ့ ေၾကျငာတဲ့ window size - advertising window size လုိ႔ေခၚပါတယ္။)
Host1 က Host2 ရဲ့ window size ၄၅၀၀ ျဖစ္ေၾကာင္းကုိသိျပီးတဲ့အတြက္ေၾကာင့္ -
၁၊ Host1 က Host2 ကုိ တခ်ိန္ထဲမွာ data ၄၅၀၀ bytes ပုိ႔ေပးလုိ႔ရတယ္။
၂၊ ၄၅၀၀ bytes ထက္ပုိတဲ့ အခ်က္အလက္ကေတာ့ Host2 ဆီက ack ရျပီးေတာ့မွ ဆက္ပုိ႔ေပးလုိ႔ရမယ္။
၃၊ Host2 က ၄၅၀၀ bytes လုံး လက္ခံရျပီးမွ ack တစ္ခါဘဲ ျပန္ပုိ႔ေပးလုိ႔ရတယ္။


ေနဂယ္ ရဲ့ Algorithm အလုပ္လုပ္ပုံကုိ အၾကမ္းေျပာရရင္ -

၁၊ ပုိ႔စရာရွိတဲ့ အခ်က္အလက္ေတြ ေတာ္ေတာ္မ်ားမ်ားရွိလုိ႔ (MSS ထက္မ်ားရင္) Packet ကုိခ်က္ခ်င္းပုိ႔ေပးပါ။ (လူျပည့္လုိ႔ ကားထြက္သြားတာေပါ့။)
၂၊ ပုိ႔စရာရွိတဲ့ အခ်က္အလက္ေတြ သိပ္မမ်ားေပမယ့္ (MSS ထက္နည္းေနေသးတယ္) acknowledgment packet ရရင္ Packet ကုိခ်က္ခ်င္းပုိ႔ေပးပါ။
၃၊ ပုိ႔စရာရွိတဲ့ အခ်က္အလက္ေတြ သိပ္မမ်ားတဲ့အျပင္ (MSS ထက္နည္းေနေသးတယ္) acknowledgment packet လည္းမရေသးရင္ packet ကုိမပုိ႔ေသးဘဲေစာင့္ေနပါ။

Operating System အားလုံးလုိလုိက ေနဂယ္ ရဲ့ Algorithm ကုိ by default အရ enable လုပ္ထားပါတယ္။ ကုိယ္တုိင္ေရးတဲ့ Program ေတြမွာ ေနဂယ္ ရဲ့ Algorithm ကုိ disable လုပ္ခ်င္ရင္ TCP_NO_DELAY ဆုိတဲ့ flag ကုိသုံးလုိ႔ရပါတယ္။ C မွာဆုိရင္ setsockopt() function ရဲ့ flag တစ္ခုျဖစ္ပါတယ္။

ေနဂယ္ ရဲ့ Algorithm ေၾကာင့္ ေကာင္းတာရွိသလုိ ဆုိးတာလဲရွိပါတယ္။ ဆုိးတာေတြထဲက ၂ ခုကုိေျပာရရင္ -
၁၊ အခ်ိန္ေပၚမွာမူတည္တဲ့ အခ်က္အလက္ေတြကုိ ပုိ႔ေပးဖုိ႔အတြက္ ေနဂယ္ ရဲ့ Algorithm ကုိ မသုံးသင့္ပါ။ ဥပမာ Stock price လုိမ်ဳိး စကၠန္႔အစိတ္အပုိင္းအတြင္းမွာ ေျပာင္းေနတဲ့ အခ်က္အလက္ေတြဟာ ေနဂယ္ ရဲ့ Algorithm က ေႏွာင့္ေႏွးေစပါတယ္။
၂၊ ေနဂယ္ ရဲ့ Algorithm နဲ႔ TCP ရဲ့ အျခား feature တစ္ခုျဖစ္တဲ့ delayed acknowledgment တုိ႔ဟာ လုံးလုံး မတဲ့တဲ့ အတြက္ေၾကာင့္ မၾကာခဏ ျပသနာတြက္တာ ၾကဳံေတြ႔ရပါတယ္။ ဒီအေၾကာင္းကုိ ေနာက္ေခါင္းစဥ္တစ္ခုနဲ႔ ထပ္ေရးသြားပါမယ္။

Wednesday, August 20, 2008

2008 US Open Diary - Aug 20


လာမယ့္ တနၤလာေန႔ (ၾသဂုတ္လ ၂၅ ရက္ေန႔) ဆုိရင္ US Open Tennis ျပဳိင္ပြဲၾကီးစေတာ့မယ္။
ႏိုင္ငံအစုံက ကစားသမားေတြ New York ကုိ ေရာက္ေနၾကျပီျဖစ္ျပီး ဒီတပတ္လုံး ျပင္ဆင္ေလ့က်င့္ ေနၾကပါတယ္။

Christian Harrison


Kyaw Kyaw Khine & Christian Harrison at USTA New York(Aug 19, 2008)
(၁၃ ႏွစ္ေအာက္ အသက္အုပ္စုမွာ အေမရိကရဲ့ နံပါတ္ ၁ တင္းနစ္ အားကစားသမား ေပါက္စ)
Christian's YouTube Clip and Profile


Stan

ဒီေန႔ ေန႔လည္ ၃ နာရီေလာက္က တင္းနစ္ကြင္းေတြဆီကုိေရာက္ေတာ့ Switzerland ႏုိင္ငံက ကမာၻ႔အဆင့္ နံပါတ္ ၁၀ ျဖစ္တဲ့ Stanislas Wawrinka ေလ့က်င့္တာကုိ သြားၾကည့္ျဖစ္ပါတယ္။ Stan က Roger Federer ရဲ့ သူငယ္ခ်င္းျဖစ္ျပီး သူတုိ႔ႏွစ္ေယာက္တြဲ Beijing Olympics မွာ ေရႊတဆိပ္ရခဲ့ပါတယ္။ အဲဒီပြဲအျပီးမွာ Roger နဲ႔ Stan ကြင္းေပၚမွာ ေအာင္ပြဲခံၾကတာကုိ ဘာလုပ္တာလဲလုိ႔ နားမလည္တဲ့အတြက္ ကၽြန္ေတာ္ Stan ကုိေမးၾကည့္ပါတယ္။

Me : Stan, Congratultaions on Olympics Gold.
Wawrinka : Thank You.
Me : I have a question if you don't mind.
(Stan looked at me as if saying "go ahead")
Me : What were you and Rog doing when celebrating on court after the final. I couldn't figure it out.
Wawrinka : (smiling) I was on fire and Roger was warming his hands.
Me : Oooooh .. I got it. Thank you very much.
(I wished I taped that conversation.)

စိတ္ကူးယဥ္တာမဟုတ္ပါဘူး။ တကယ္ေမးခဲ့တာပါ။ ကၽြန္ေတာ္ အရမ္းေပ်ာ္ျပီး ျပန္လာခဲ့တယ္ဆုိတာ သိပ္ေျပာဖုိ႔လုိမယ္မထင္ပါဘူး။

Players

ဒီေန႔ၾကည့္ခဲ့တဲ့ အားကစားသမားမ်ားရဲ့ ဓါတ္ပုံေတြ။


Tomas Berdych (Czech)




Marat Safin (Russian)




Nicholas Kiefer (German)



Feliciano Lopez (Spanish)


Monday, August 11, 2008

Latency (4)



၄၊ Processing/Forwarding Delay (Packet တစ္ခု Router သုိ႔မဟုတ္ Switch အထဲမွာ "ၾကာတဲ့အခ်ိန္")

Router အလုပ္လုပ္ပုံ အေျခခံ

၁၊ ေရာက္လာတဲ့ Frame ရဲ့ CRC (FCS) တန္ဖုိးကုိ တြက္ခ်က္စစ္ေဆးတယ္။ တန္ဖုိး မကုိက္ဖူး၊ မွားေနတယ္ဆုိရင္ Frame ကုိ လက္မခံဘဲ ဖ်က္ျပစ္လုိက္တယ္။ (ဒီအဆင့္ကေတာ့ Switch မွာ အလုပ္လုပ္ပုံနဲ႔ တူပါတယ္၊)
၂၊ CRC (FCS) တန္ဖုိး မွန္တယ္ဆုိရင္ Frame ထဲကေန Layer 3 အခ်က္အလက္ကုိ ထုတ္ယူပါတယ္။ အထုပ္ေျဖခ်င္း (de-encapsulation) လုိ႔ ေခၚပါတယ္။
၃၊ De-encapsulate လုပ္ျပီးရလာတဲ့ Packet ရဲ့ ထိပ္မွာပါတဲ့ Header Checksum ကုိ တြက္ခ်က္စစ္ေဆးပါတယ္။ တန္ဖုိးမကုိက္ဖူး မွားေနတယ္ဆုိရင္ Packet ကုိ လက္မံဘဲ ဖ်က္ျပစ္လုိက္တယ္။
၄၊ Packet မွာပါတဲ့ Destination IP address ကုိဖတ္ျပီး Routing Table ထဲမွာ လုိက္ရွာတယ္။ Routing Table ဆုိတာ IP address ရယ္၊ ေနာက္တဆင့္မွာသြားရမဲ့ Router ရဲ့ IP address (next hop IP) ရယ္၊ Router ရဲ့ထြက္ေပါက္ (output interface)ဆုိတဲ့ အခ်က္ ၃ ခုကုိ တြဲမွတ္ထားတဲ့ ဇယားျဖစ္ပါတယ္။ Router Table ထဲမွာ လုိက္ရွာလုိ႔ေတြ႔ရင္၊ ေနာက္တဆင့္သြားရမဲ့ Router ရဲ့ IP address (next hop IP) နဲ႔ Router ရဲ့ထြက္ေပါက္ (output interface) ေတြကုိသိမွာျဖစ္ပါတယ္။ Routing Table ထဲမွာ ရွာလုိ႔မေတြ႔ရင္ေတာ့ အဲဒီ Packet ကုိ ဖ်က္ျပစ္လုိက္မွာ ျဖစ္ျပီး Packet ကုိပုိ႔ေပးတဲ့ မူလကြန္ပ်ဴတာဆီကုိ မပုိ႔ေပးႏုိင္တဲ့သတင္း ICMP နဲ႔ ျပန္လည္ အေၾကာင္းၾကားေပးမွာျဖစ္ပါတယ္။ ဒီလုိျဖစ္တာကုိ (Routing Table Lookup Failure) လုိ႔ေခၚပါတယ္။

Routing Table ထဲမွာ ရွာေတြ႔တယ္ဆုိပါစုိ႔၊
၅၊ Router တစ္ခုကုိျဖတ္သြားတာ ျဖစ္တဲ့အတြက္ေၾကာင့္ TTL (Time To Live) တန္ဖုိးကုိ ၁ ႏွုတ္ပါမယ္။ ႏွုတ္ျပီးလုိ႔ TTL တန္ဖုိး သုညထက္ၾကီးဖုိ႔ လုိပါတယ္။ TTL တန္ဖုိး သုညျဖစ္သြားရင္ Packet ရဲ့သက္တန္းကုန္သြားျပီ ျဖစ္တဲ့အတြက္ Router က Packet ကုိဖ်က္ဆီးျပစ္လုိက္ျပီး မူလ ကြန္ပ်ဴတာဆီကုိ TTL သုညျဖစ္သြားလုိ႔ ဖ်က္ဆီုျပစ္လုိက္ရတဲ့အေၾကာင္း ICMP နဲ႔ သတင္းျပန္ပုိ႔ေပးပါတယ္။ (ဒီအလုပ္လုပ္ပုံကုိ Traceroute program မွာ သုံးတဲ့အေၾကာင္း ေခါင္းစဥ္တစ္ခုနဲ့ ေရးခဲ့ဖူးပါတယ္၊)
၆၊ TTL တန္ဖုိး ေျပာင္းသြားတဲ့အတြက္ IP Header ရဲ့ Checksum ကုိျပန္လည္ တြက္ခ်က္ရပါတယ္။ (ကၽြန္ေတာ့ သူငယ္ခ်င္း တစ္ေယာက္ အလုပ္အင္တာဗ်ဴးမွာ အျမဲတန္း ေမးတဲ့ ေမးခြန္းပါ၊)

Routing Table ထဲမွာဘယ္ကုိပုိ႔ရမယ္လုိ႔ ရွာေတြ႔ျပီးတဲ့ေနာက္မွာေတာ့ Packet ကုိ ထြက္ေပါက္ကေန ထုတ္လႊတ္ဖုိ႔ျပင္ဆင္ရပါမယ္။

ရ၊ Packet ကုိ layer 2 အခ်က္အလက္ေတြနဲ႔ ျပန္လည္ ထုပ္ပုိးဖုိ႔ (encapsulation) လုိပါမယ္။ ေနာက္တဆင့္ Router (next hop IP) ရဲ႔ MAC address ကုိ ARP Table (address resolution protocol)ဇယားထဲကေနရွာပါမယ္။
၈၊ ARP Table ကရတဲ့ အခ်က္အလက္ကုိယူျပီး IP Packet ကုိ layer 2 frame ထဲကုိ ထုပ္ပုိးျပီး အတြက္ေပါက္ကေန ထုတ္လႊတ္ေပးလုိက္ပါတယ္။ (Layer 2 CRC (FCS)) တြက္ခ်က္တာလည္း ဒီအဆင့္မွာပါပါတယ္။

Switch - CAM Table ထဲမွာ Destination Address ကုိရွာလုိ႔မေတြ႔ရင္ (lookup failure ျဖစ္လ်င္) Frame ကုိထြက္ေပါက္အားလုံးကုိ ပုိ႔ေပးလုိက္တယ္၊
Router - Routing Table ထဲမွာ Destination Address ကုိရွာလုိ႔မေတြ႔ရင္ (lookup failure ျဖစ္လ်င္) Packet ကုိ ေရွ႔ဆက္မပုိ႔ေတာ့ဘဲ ဖ်က္ဆီးျပစ္လုိက္တယ္။

- ဆုိတာ Router နဲ့ Switch အဓိက ကြာျခားခ်က္ေတြထဲက တစ္ခုျဖစ္ပါတယ္။

အထက္မွာေျပာတဲ့အဆင့္ေတြလုပ္ဖုိ႔ ၾကာတဲ့အခ်ိန္ကေတာ Router တစ္ခုရဲ့ Processing/Forwarding delay ျဖစ္ပါတယ္။ ဘယ္ႏွစ္စကၠန့္ ၾကာတယ္ ဆုိတာကေတာ့ Router ရဲ့ manufacturer, model, software/hardware architecture ေပၚမွာ မူတည္ျပီး အမ်ဳိးမ်ဳိး ကြဲျပားပါတယ္။

ကၽၽြန္ေတာ္ လက္ေတြ႔ေလ့လာမိသေလာက္ Cisco က ထုတ္လုပ္တဲ့ Router ေတြမွာ ပါတဲ့ software architecture ေတြထဲက -
၁၊ Process switching - ေရွးအက်ဆုံး၊ အေႏွးဆုံး နည္းလမ္းျဖစ္ပါတယ္။ အထက္မွာ ေဖၚျပခဲ့တဲ့ အဆင့္ေတြအားလုုံးကုိ CPU တစ္ခုထဲကတာ၀န္ယူပါတယ္။
၂၊ Fast switching - Packet တစ္ခု Router ထဲမွာျဖတ္သြားျပီးလ်င္ cache entry တစ္ခု memory ထဲမွာ တည္ေဆာက္ လုိက္ပါတယ္။ ေနာက္လာတဲ့ Packet ေတြက အရင္ Packet နဲ့တူတယ္ဆုိရင္ table lookup အဆင့္ေတြ လုပ္စရာမလုိေတာ့ဘဲ cache ကေန အခ်က္အလက္ေတြကုိ ယူျပီး packet ကိုပုိ႔ေပးလုိက္ပါတယ္။ Process switching ထက္ ပုိျမန္တာေပါ့၊
၃၊ CEF switching - Cisco ရဲ့ အဆင့္ျမင့္ packet forwarding နည္းလမ္းျဖစ္ပါတယ္။ Router table ရယ္၊ ARP Table ကုိ ေပါင္းထားတဲ့ CEF Table အျပင္ အနီးအနားမွာရွိတဲ့ Router ေတြရဲ့ အခ်က္အလက္ကုိစုေဆာင္းထားတဲ့ဇယား (adjacency table) တုိ႔တြဲျပီး အလုပ္လုပ္ပါတယ္။ CEF ဆုိတာကေတာ့ Cisco Express Forwarding ျဖစ္ပါတယ္။ Routing table ကုိ 256-way m-trie data structure နဲ႔ တည္ေဆာက္ထားပါတယ္။

အထက္မွာေျပာခဲ့တဲ့ Process switching, fast switching and CEF switching မွာပါတဲ့ switching ဆုိတဲ့စကားလုံး ဟာ Router တစ္ခုထဲမွာ Packet တစ္ခုကုိ အ၀င္ေပါက္ကေန၊ အထြက္ေပါက္ကုိ ဘယ္လုိေရာက္ေအာင္ ပုိ႔ေပးတယ္ဆုိတဲ့ နညး္လမ္းျဖစ္ပါတယ္။ Switch တစ္ခုမွာ အလုပ္လုပ္တဲ့ switching နဲ႔ မတူပါဘူး။
အသးစိတ္ေလ့လာခ်င္လ်င္ ဒီစာအုပ္ကုိ ဖတ္ပါ

Router ထဲမွာ ၾကာတဲ့အခ်ိန္က Packet ကုိ တေနရာက တေနရာကုိပုိ႔ေပးဖုိ႔တင္ မက အျခား အလုပ္ပုိေတြလည္းလုပ္ရတာ ျဖစ္ႏုိင္ပါတယ္။ ဥပမာ
၁၊ NAT - Network Address Translation ကြန္ပ်ဴတာ အမ်ားၾကီးကုိ Public IP address တစ္ခုထည္းမွာ ေ၀ငွ သုံးဖုိ႔ အသုံးမ်ား ပါတယ္။ အိမ္ေတြမွာေရာ၊ ရုံးေတြမွာပါ သုံးၾကပါတယ္။
၂၊ ACL - Access Control List ဘယ္ application ၊ ဘယ္ IP address ကုိခြင့္ျပဳခ်င္တယ္၊ မျပဳခ်င္ဘူး ဆုိတာေပၚ မူတည္ျပီး သုံးပါတယ္။ Internet Service Provider က အိမ္သုံးကြန္ပ်ဴတာေတြ web server မလုပ္ေစခ်င္ရင္ TCP Port 80 ကုိ ပိတ္ထားတာမ်ဳိးေပါ့။
၃၊ QoS - Quality of Service ဘယ္ application ၊ ဘယ္ IP address ကုိ bandwidth မ်ားမ်ားပုိေပးခ်င္တယ္၊ priority ပုိေပးခ်င္တယ္ဆုုိရင္ သုံးတာမ်ဳိးျဖစ္ပါတယ္။ အင္တာနက္ ဖုံးနဲ႔၊ အင္တာနက္ ဗီဒီယုိ အသုံးျပဳသူမ်ားအတြက္ အထူးလုိအပ္ပါတယ္။

Saturday, August 9, 2008

Latency (3)



၄၊ Processing/Forwarding Delay (Packet တစ္ခု Router သုိ႔မဟုတ္ Switch အထဲမွာ "ၾကာတဲ့အခ်ိန္")

Packet တစ္ခု Switch တစ္ခု ထဲကုိ၀င္လာျပီးရင္ ဘယ္အဆင့္ေတြကုိ ျဖတ္သန္းသြားရမလဲ ?
Packet တစ္ခု Router တစ္ခု ထဲကုိ၀င္လာျပီးရင္ ဘယ္အဆင့္ေတြကုိ ျဖတ္သန္းသြားရမလဲ ?

အလုပ္အင္တာဗ်ဴးမွာ အလြန္ေမးလုိ႔ေကာင္းတဲ့ေမးခြန္း ၂ ခုျဖစ္ပါတယ္။

Switch အလုပ္လုပ္ပုံ အေျခခံ
၁၊ ေရာက္လာတဲ့ Frame ရဲ့ CRC (FCS) တန္ဖုိးကုိ တြက္ခ်က္စစ္ေဆးတယ္။ တန္ဖုိး မကုိက္ဖူး၊ မွားေနတယ္ဆုိရင္ Frame ကုိ လက္မခံဘဲ ဖ်က္ျပစ္လုိက္တယ္။
၂၊ CRC (FCS) တန္ဖုိး မွန္တယ္ဆုိရင္ Frame ရဲ့ Destination Address ကုိဖတ္ျပီး၊ Switch ရဲ့ Mac-address-table ထဲမွာ အဲဒီ destination address ကုိလုိက္ရွာပါတယ္။ Mac-address table ကုိ CAM Table - Content Addressable Memory Table လုိ႔လဲေခၚပါတယ္။ CAM Table ဆုိတာကေတာ့ ဘယ္ MAC Address က ၊ Switch ရဲ့ ဘယ္အေပါက္ (port) မွာ ရွိတယ္ဆုိတာကုိ မွတ္ထားတဲ့ ဇယားျဖစ္ပါတယ္။ တနည္းေျပာရင္ ဘယ္ကြန္ပ်ဴတာက Switch ရဲ့ ဘယ္အေပါက္မွာ ခ်ိတ္ထားတယ္ဆုိတာကုိ မွတ္ထားတဲ့ ဇယားျဖစ္ပါတယ္။
၃၊ CAM Table ထဲမွာ Destination address ကုိ ရွာလုိ႔ေတြ႔ရင္၊ အဲဒီ MAC address နဲ႔ သက္ဆုိင္တဲ့ အေပါက္ကေန Frame ကုိ ထုတ္လႊတ္ ေပးလုိက္ပါတယ္။
၄၊ CAM Table ထဲမွာ Destination address ကုိ ရွာလုိ႔မေတြ႔ရင္၊ Frame ကုိ လက္ခံရတဲ့အေပါက္ကလြဲလုိ႔၊ အေပါက္တုိင္းကုိ ထုတ္လႊတ္ ေပးလုိက္ပါတယ္။
(CRC = Cyclic Redundancy Check)
(FCS = Frame Check Sequence)

Switch ကုိေျပာတဲ့အခါမွာ Packet အစား၊ Frame လုိ႔သုံးတာ သတိျပဳပါ။ OSI ခုႏွစ္လႊာ အလုိအရ Layer 2 က unit က Frame ျဖစ္ျပီးေတာ့၊ Layer 3 က unit က Packet ျဖစ္ပါတယ္။

Switch ေတြ ဘယ္ေလာက္ ျမန္ျမန္နဲ႔ Frame ကုိ ပုံေပးႏုိင္သလဲဆုိတာ ဇယားထဲမွာ ဘယ္ေလာက္ျမန္ျမန္ရွာႏိုင္သလဲ၊ Frame ကုိ ဘယ္အခ်ိန္မွာ စတင္ ထုတ္လႊတ္မလဲ ဆုိတဲ့ အခ်က္ေတြေပၚမွာ မူတည္ပါတယ္။

ဇယားထဲမွာ ဘယ္ေလာက္ျမန္ျမန္ရွာႏုိင္သလဲဆုိတာ ကေတာ့ ဇယားအရြယ္အစားဘယ္ေလာက္ၾကီးသလဲ (ကြန္ပ်ဴတာေတြ ဘယ္ေလာက္မ်ားမ်ား Switch မွာ လာခ်ိတ္ထားသလဲ)၊ Switch ရဲ့memory တုိ႔၊ CPU တုိ႔က ဘယ္ေလာက္ျမန္ျမန္ အလုပ္လုပ္ႏုိင္သလဲဆုိတာေပၚမွာ တည္ပါတယ္။

Frame ကုိ ဘယ္အခ်ိန္မွာ ထုတ္လႊတ္မလဲဆုိတာကေတာ့ Switch က အသုံးျပဳတဲ့နည္းလမ္း (switching method) နဲ႔ဆုိင္ပါတယ္။
၁၊ cut-through switching - Switch က အ၀င္ေပါက္မွာ destination address ကုိ လက္ခံရရွိျပီဆုိတာနဲ႔ ဇယားမွာရွာျပီး အထြက္ေပါက္ကုိ ပုိ႔ေပးတဲ့ နည္းလမ္းျဖစ္ပါတယ္။ ေကာင္းက်ဳိးကေတာ့ အရမ္းျမန္တာေပါ့၊ ဆုိးက်ဳိးကေတာ့ Frame က လမ္းမွာ အမွား တစ္ခုခုျဖစ္ခဲ့တယ္ဆုိတာကုိ switch က မစစ္ေဆးေတာ့တဲ့အတြက္ ပ်က္စီးေနတဲ့ frame ကုိ ခ်ိတ္ထားတဲ့ကြန္ပ်ဴတာေတြ ရသြားႏုိင္ပါတယ္။ အထက္မွာေရးခဲ့တဲ့ အဆင့္ေတြထဲက အဆင့္ (၁) CRC (FCS) စစ္ေဆးတဲ့အဆင့္ကုိ မလုပ္တဲ့ နည္းလမ္းျဖစ္ပါတယ္။
၂၊ fragment free switching - switch က frame ရဲ့ ပထမ ၆၄ bytes ကုိ လက္ခံရရွိတဲ့အခ်ိန္အထိေစာင့္ျပီးမွ ဇယားမွာရွာျပီး အထြက္ေပါက္ကုိပုိ႔ေပးပါတယ္။
Frame တစ္ခုရဲ့အရြယ္က ၆၄ bytes ထက္ ငယ္တယ္ဆုိရင္ Runt (အေသးေလး) လုိ႔ေခၚပါတယ္။ IEEE Ethernet Standard မွာ Frame တစ္ခုရဲ့အရြယ္ဟာ အနည္းဆုံး ၆၄ bytes ရွိရမယ္လုိ႔ သတ္မွတ္ထားပါတယ္။ Runt Frame ျဖစ္ရတဲ့ အဓိက အေၾကာင္းကေတာ့ ကြန္ပ်ဴတာ ႏွစ္လုံးက Frame ကုိ တစ္ျပဳိင္ထဲ ပုိ႔လုိက္ၾကလုိ႔ လမ္းခုလပ္မွာ Frame ေတြ အခ်င္းခ်င္း တုိက္မိၾကရင္း (collision) ျဖစ္တာပါ။ ေကာင္းက်ဳိးကေတာ့ cut-through switching ေလာက္နီးနီးျမန္ျပီး၊ Runts (အေသးေလး) ေတြ မဟုတ္တာ ေသခ်ာေအာင္ စစ္ျပီးသြားျဖစ္သြားပါတယ္။ ဆုိးက်ဳိးကေတာ့ cut-through switching လုိဘဲ CRC (FCS) စစ္ေဆးတဲ့အဆင့္မရွိတာေပါ့။
၃၊ store and forward switching - switch က frame တစ္ခုလုံးကုိ အ၀င္ေပါက္ကလက္ခံ၊ CRC (FCS) တန္ဖုိးကုိတြက္ခ်က္စစ္ေဆး ျပီးေတာ့မွ ဇယားထဲမွာရွာၾကည့္ျပီး အထြက္ေပါက္ကုိ ပု႔ိေပးပါတယ္။ အျခား switching နည္းလမ္းေတြနဲ႔ ယွဥ္ၾကည့္ရင္ေတာ့ ပုိေႏွးတာေပါ့။

ေနာက္ဆုံးေပၚ switch ေတြရဲ့ CPU ေတြက အရမ္းျမန္ေနျပီျဖစ္တာေၾကာင့္ store-and-forward switching နည္းလမ္းကုိဘဲ အျမဲတမ္း သုံးသင့္ပါတယ္။

ဘြတ္ရွ္ နဲ႔ ပူတီ-ပူး


"ပူတီ-ပူး" ဆုိတာ ရုရွား၀န္ၾကီးခ်ဳပ္ ပူတင္ကုိ အေမရိကန္လက္ရွိသမၼတ ေဂ်ာ့ဘြတ္ရွ္ ေပးထားတဲ့နာမည္ျဖစ္ပါတယ္။
"သူမ်က္လုံးထဲကုိၾကည့္လုိက္ေတာ့ အမွန္အတုိင္းေျပာတဲ့သူ၊ ယုံၾကည္စိတ္ခ်ရတာသူျဖစ္တာ္လုိ႔ ငါျမင္လုိက္ရတယ္" လုိ႔ ၂၀၀၁ ခုႏွစ္ ဇြန္လမွာ ဘြတ္ရွ္က ပူတင္နဲ႔ေတြ႔ျပီး မၾကာခင္ျပဳလုပ္တဲ့ သတင္းစာရွင္းလင္းပြဲမွာ ေျပာခဲ့ပါတယ္။

မေန႔က ပီကင္းမွာျပဳလုပ္တဲ့ အုိလမ္ပစ္ဖြင့္ပဲြမွာ ၀န္ၾကီးခ်ဳပ္ ပူတင္က၊ သမၼတ ဘုရွ္ရဲ့ တစ္ခုံေၾကာ္မွာ ထုိင္ေနတာေတြ႔ပါတယ္။ အဲဒီ အုိလမ္ပစ္ ဖြင္႔ပြဲလုပ္ေနတဲအခ်ိန္နဲ႔ တစ္ခ်ိန္ထဲလုိလုိမွာ ရုရွား စစ္တပ္ေတြက ေဂ်ာ္ဂ်ီယာႏုိင္ငံကုိ စတင္၀င္ ေရာက္တုိက္ခုိက္ပါတယ္။

ဒီသတင္းႏွစ္ခုကုိ တစ္ျပဳိင္ထဲေတြ႔ေတာ ကၽြန္ေတာ့စိတ္ထဲမွာေပၚလာတဲ့ အေတြးႏွစ္ခုကေတာ့ -
၁၊ ဘြတ္ရွ္က ေဘးမွာထုိင္ေနတဲ့ပူတင္ကုိ ဘာမ်ားေျပာေလမလဲ၊ ပူတင့္ မ်က္လုံးထဲကုိၾကည့္ျပီး ဘာမ်ားျမင္ေလမလဲ။
၂၊ Godfather ရုပ္ရွင္ အပုိင္း ၂ ရဲ့ ဇာတ္သိမ္းခမ္းတုိင္းမွာ Coleone မိသားစုရဲ့ ရန္သူေတြကုိ တစ္ေယာက္ျပီး တစ္ေယာက္ လုိက္သတ္ေနတဲ့ အခ်ိန္မွာ Michael Coleone ကေတာ့ သူတူရဲ့ ႏွစ္ခ်င္းခံပြဲမွာ မွာ မိသားစု လူၾကီးတစ္ေယာက္အေနနဲ႔ တက္ေနတာကုိ - သြားသတိရမိပါတယ္။

၂၀၀၁ ခုႏွစ္ က သတင္းစာရွင္းလင္းပြဲ
"I looked the man in the eye. I found him to be very straightforward and trustworthy." - George W. Bush

Friday, August 8, 2008

Latency (2)



၃၊ Queueing Delay (Packet တစ္ခုကုိ Device တစ္ခုက ထုတ္လႊတ္ဖုိ႔ တန္းစီေစာင့္ေနစဥ္မွာ "ၾကာတဲ့အခ်ိန္")

ရုပ္ရွင္ေကာင္းလုိ႔ သမၼတရုံမွာ လက္မွတ္၀ယ္တဲ့အခါ လူတန္းရွည္ၾကီးနဲ႔ေစာင့္ရတာ မွတ္မိပါေသးတယ္၊ (ေမွာင္ခုိ၀ယ္ရင္ေတာ့ ေစာင့္စရာမလုိဘူးေပါ့)။ ဒီလုိ လူတန္းရွည္ၾကီးကုိ queue လုိ႔ေခၚျပီး၊ တန္းစီျပီး ေစာင့္ရတာကုိ queueing လုိ႔ ေျပာႏုိင္ပါတယ္။

ဘာေၾကာင့္လူတန္းအရွည္ၾကီးျဖစ္ရတာလဲဆုိရင္ လက္မွတ္ေရာင္းတဲ့လူအေရအတြက္ကလည္း သိပ္မမ်ား၊ ေႏွးကလဲေႏွးတဲ့အခ်ိန္မွာ လက္မွတ္၀ယ္ခ်င္တဲ့လူေတြက အမ်ားၾကီးျဖစ္ေနလုိ႔ေပါ့။ ဒီလုိဘဲ Router တစ္ခုမွာ အျပင္ကုိ Transmit လုပ္ရမဲ့ Packet ေတြကမ်ားျပီး၊ output interface က ေႏွးေနခဲ့ရင္၊ Router ရဲ့ အထြက္ေပါက္မွာ packet ေတြ စီေစာင့္ေနရပါတယ္။ ဘယ္ေလာက္ၾကာၾကာ ေစာင့္ရသလဲ ဆုိတာကေတာ့ ေရွ.မွာ Packet ဘယ္ေလာက္မ်ားမ်ားရွိသလဲဆုိတာရယ္၊ Router interface က ဘယ္ေလာက္ျမန္ျမန္ Transmit လုပ္ေပးႏုိင္သလဲ (တနည္းေျပာရရင္ serialization delay ဘယ္ေလာက္ၾကာသလဲ) ဆုိတာေပၚမွာ မူတည္ပါတယ္။ ရုပ္ရွင္ရုံမွာ ကုိယ့္ေရွ.ကလူတန္းဘယ္ေလာက္ရွည္သလဲ၊ လက္မွတ္ေရာင္း တဲ့လူက ဘယ္ေလာက္ အလုပ္ျမန္ျမန္လုပ္သလဲ ဆုိတာမူတည္သလုိေပါ့။

လက္မွတ္၀ယ္ဖုိ႕႔ေစာင့္ေနရင္း၊ ကုိယ္အလွည့္ေရာက္ခါနည္းမွ လက္မွတ္ကုန္သြားျပီဆုိရင္ ေနာက္ပြဲ ေစာင့္ၾကည့္ရင္ၾကည့္၊ ေနာက္ေန႔ ျပန္လာခ်င္လာ၊ ဒါမွ မဟုတ္လဲ့ မၾကည့္ဘဲ အိမ္ျပန္ေတာ့ေပါ့။ အထြက္ေပါက္မွာ ေစာင့္ေနတဲ့ packet ေတြမ်ားလြန္းလုိ႔ မေစာင့္ႏုိင္ေတာ့ရင္ Router က packet ေတြကုိ ဖ်က္ျပစ္လုိက္ပါတယ္။ ဒါကုိ Output queue drop လုိ႔ ေခၚပါတယ္။ ဒီလုိ output queue drop ျဖစ္ရင္ router က packet ကိုၾကဳိးစားျပီးထပ္ပုိ႔ေပးဖုိ႔တာ၀န္ မရွိပါဘူး။ Router က drop လုပ္လုိက္တဲ့သတင္းကုိေတာ့ packet ကုိပုိ႔ေပးတဲ့ source computer ဆီကုိေတာ့ ျပန္အေၾကာင္းၾကားေပးပါတယ္။ ျပန္ပုိ႔ခ်င္၊ မပုိ႔ခ်င္ဆုိတာကေတာ့ source computer ရဲ့ သေဘာေပါ့။

VIP တစ္ေယာက္နဲ႔သိလုိ႔ဘဲျဖစ္ျဖစ္၊ ေမွာင္ခုိကဘဲ ေစ်းၾကီးေပး၀ယ္၀ယ္ - တနည္းနည္းနဲ႔ လူတန္းအရွည္ၾကီးမွာ ေစာင့္မေနဘဲ ခ်က္ခ်င္းလက္မွတ္ရတဲ့နည္းေတြရွိပါတယ္။ Network မွာလည္း queue ထဲမွာ ေစာင့္မေနႏုိင္တဲ့ Packet အမ်ဳိးအစား ေတြရွိပါတယ္။
ဥပမာ
- အင္တာနက္ေပၚမွာ ဖုံးေျပာတဲ့ (Voice over IP) packet ေတြဟာ လမ္းမွာၾကာေနခဲ့ရင္ နားေထာင္တဲ့သူမွာ ေလးလုံးမကြဲျဖစ္ပါလိမ့္မယ္။
- E-mail packet ေတြကေတာ့ လမ္းမွာ ၾကာေနလည္း e-mail ဖတ္သူဆီမွာ ဘာမွ ျပသနာ မရွိပါဘူး။

Router တစ္ခုရဲ့ထြက္ေပါက္မွာ e-mail packet ၁၀ ခုကေစာင့္ေနခ်ိန္မွာ၊ Voice over IP Packet တစ္ခု ေနာက္က ေရာက္လာတယ္ဆုိပါစုိ႔။ Router အေနနဲ႔ VoIP packet ကုိ ၾကားျဖတ္ျပီး အျမန္ဆုံးပုိ႔ေပးဖုိ႔လုိပါတယ္။ ဒီလုိလုပ္ႏုိင္ဖုိ႔ နည္းလမ္းေပါင္း မ်ားစြာရွိတဲ့အထဲက priority queueing ကေတာ့ အလြယ္ဆုံးနဲ႔၊ လူသုံးအမ်ားဆုံး ျဖစ္ပါတယ္။

Priority queue အလုပ္လုပ္ပုံကေတာ့ -
Router ရဲ့ memory မွာ
၁၊ normal priority queue နဲ႔
၂။ high priority queue ဆုိျပီး ႏွစ္မ်ဳိးခြဲထားပါတယ္။ Router က high priority queue မွာ packet ေတြ႔တုိင္း normal priority queue မွာ packet ဘယ္ေလာက္ရွိေနေန ၾကားျဖတ္ျပီး အရင္ဆုံးပုိ႔ေပးပါတယ္။

Queueing delay ကုိအဆုံးသတ္ရရင္ -
Queueing delay ဆုိတာ router ရဲ့ output interface မွာ packet ေတြစီေစာင့္ေနရလုိ႔ၾကာတဲ့အခ်ိန္ျဖစ္ပါတယ္။ အဲဒီ packet ေတြဟာ router ရဲ့ output queue ထဲမွာထိုင္ေစာင့္ေနၾကပါတယ္။ ဘယ္ေလာက္ၾကာၾကာ ေစာင့္ရသလဲဆုိတာက ၁၊ output interface ရဲ့ serialization delay နဲ႔ ၂၊ output queue ထဲမွာ packet ဘယ္ေလာက္မ်ားမ်ားရွိလဲ ေပၚမွာ တည္ပါတယ္။ အခ်ိန္ေႏွးတာကုိ သည္းမခံႏုိင္တဲ့ application ေတြ (ဥပမာ - အင္တာနက္ဖုံး၊ အင္တာနက္ဗီဒီယုိ) အတြက္ ၾကားျဖတ္ျပီးအျမန္ပုိ႔ေပးတဲ့ queueing နည္းလမ္းေတြရွိပါတယ္။
Router မွာ input queue delay ရွိေပမယ့္ output queue delay နဲ႔ႏွုိင္းယွဥ္ၾကည့္ရင္ တန္ဖုိးအရမ္း နည္းတာေၾကာင့္ စဥ္းစားဖုိ႔ မလုိအပ္ပါဘူး။

Tuesday, August 5, 2008

Latency


လြန္ခဲ့တဲ့ ၁၂ ႏွစ္ေလာက္ကေရးခဲ့တဲ့ "အဲဒါ Latency ေၾကာင့္ေပါ့၊ ငတုံးရဲ့" ဆုိတဲ့ေဆာင္းပါးကုိ ဟုိတေန႔က ျပန္ဖတ္မိရင္းနဲ႔ ကၽြန္ေတာ္ ေလ့လာ နားလည္သေလာက္ Latency နဲ႔ ပတ္သက္တာကုိ ေျပာသြားပါမယ္။

Latency ဆုိတာကုိ ဗမာလုိ "ၾကာတဲ့အခ်ိန္" လုိ႔ေျပာရင္ နီးစပ္မယ္ထင္ပါတယ္။ Network တစ္ခုကုိျဖတ္ျပီး ကြန္ပ်ဴတာ ၂ လုံး အဆက္အသြယ္လုပ္ၾကတဲ့အခါ လမ္းခုလတ္မွာ "ၾကာတဲ့အခ်ိန္" အနည္းဆုံး ၅ မ်ဳိးခြဲလုိ႔ ရပါတယ္။ အဲဒါေတြကေတာ့

၁၊ Serialization Delay
၂၊ Propagation Delay
၃၊ Queueing Delay
၄၊ Processing / Forwarding Delay
၅၊ Network Delay

၁၊ Serialization Delay (Packet တစ္ခုကုိ Device တစ္ခုက ထုတ္လႊတ္ဖုိ႔ "ၾကာတဲ့အခ်ိန္")

ဘူတာတစ္ခုမွာ မီးရထားတစင္း ရပ္ထားတယ္ဆုိပါစုိ႔။ ေခါင္းတြဲ စထြက္တဲ့အခ်ိန္ကစလုိ႔၊ ေနာက္ဆုံးဂတ္ဗုိလ္တြဲ ဘူတာရုံက ကလုံးလုံး ထြက္သြားတဲ့အထိ ၾကာတဲ့အခ်ိန္ကုိ ရထားတြဲရဲ့ serialization delay လုိ႔ေျပာႏုိင္ပါတယ္။

ေအာက္မွာ ျပထားတဲ့ပုံကုိၾကည့္ျပီးေဆြးေႏြးသြားပါမယ္။ Serilization delay ဆုိတာ Network hardware ကေန packet တစ္ခုကို
၀ါယာၾကဳိးေပၚကုိ (wireless ဆုိရင္လဲ ေလထဲကုိေပါ့) တစ္ေပးဖုိ႔လုိ႔ ၾကာတဲ့အခ်ိန္ကုိ ေျပာတာျဖစ္ပါတယ္။ Network hardware ရဲ့ speed ျမန္ေလေလ၊ serilization delay တန္ဖုိး နည္းေလေလျဖစ္ပါတယ္။

ပုံမွာျပထားတဲ့အတုိင္း HostA က ေန ၁၅၀၀ bytes packet ကုိ transmit လုပ္ဖုိ႔ ၀.၁၂ မီလီစကၠန္႔ၾကာျပီး၊ အဲဒီ packet ကုိဘဲ Router2 က transmit လုပ္ဖုိ႔ ၉၃ မီလီစကၠန္႔ ၾကာပါတယ္။ တစ္ခုမွတ္ထားေစခ်င္တာကေတာ့ Network hardware က packet တစ္ခုကုိ လက္ခံ ရရွိတဲ့အခါ serialization delay မရွိပါဘူး။

ဘဏ္ေတြနဲ႔၊ စေတာ့ရွယ္ရာ အေရာင္းအ၀ယ္လုပ္တဲ့ အဖြဲ႔အစည္းေတြမွာ - Circuit တစ္ခုကုိ ငွားတဲ့၊ ၀ယ္တဲ့အခါမွာ bandwidth မလုိအပ္ေသာ္လည္း၊ serialization delay နည္းေစခ်င္တဲ့အတြက္ေၾကာင့္ ပုိက္ဆံပုိေပးျပီး Higher bandwidth circuit ေတြကုိ
၀ယ္ၾကတာ သတိျပဳမိပါတယ္။


serialization delay


Serialization Delay = Packet Size / Link Speed
Total Serialization Delay = Summation of Serialization at every hop

၂၊ Propagation Delay (အကြာအေ၀းေပၚမွာ မွီျပီး "ၾကာတဲ့အခ်ိန္")

မီးရထားတစင္း ဘူတာရုံကထြက္လာတာကုိ ေကာင္းကင္ကေနၾကည့္ၾကည့္မယ္ ဆုိပါစုိ႔။ ေခါင္းတြဲ ပထမဘူတာရုံကထြက္လာတဲ့အခ်ိန္ စျပီး၊ အဲဒီေခါင္းတြဲ ဒုတိယဘူတာရုံကုိ ၀င္သြားတဲ့အခ်ိန္အထိ ၾကာတဲ့အခ်ိန္ကုိ ရထားရဲ့ ဘူတာႏွစ္ခုၾကားက propagation delay လုိ႔ ေခၚပါမယ္။

ဒီတန္ဖုိးကေတာ့ နားလည္ရလြယ္ပါတယ္။ Bandwidth ဘယ္ေလာက္ မ်ားမ်ား propagation delay ကုိ ေလ်ာ့နည္းေစခ်င္လုိ႔မရပါဘူး။ ဘာေၾကာင့္လည္းဆုိေတာ့ အလင္းရဲ့အျမန္ႏွုန္း (လ်ွပ္စစ္ရဲ့ အျမန္ႏုွန္း) ဆုိတာ ကိန္းေသျဖစ္ေနလုိ႔ပါ။ ရူပေဗဒ နည္းနည္းပါးပါး သင္ဖူး သူတုိင္း အလင္းေရာင္ဟာ တစကၠန္႔ကုိ မီတာ သန္း ၃၀၀ ႏွုန္းနဲ႔သြားတယ္ဆုိတာ သိၾကမယ္ထင္ပါတယ္။ Network တစ္ခု မွာေတာ့ လွ်ပ္စစ္ နဲ႔ အလင္း ေျပာင္းလဲတဲ့ အဆင့္ေတြရွိတာေၾကာင့္ အလင္း အလွ်င္ရဲ့ ၇၀% နဲ႔ Packet ေတြသြားတယ္လုိ႔ အမ်ားစုက လက္ခံထား ၾကပါတယ္။
မွတ္ထားေစခ်င္တာကေတာ့ propagation delay က packet size နဲ႔ေရာ၊ bandwidth နဲ႔ပါ မဆုိင္ပါဘူး ဆုိတဲ့အခ်က္ပါ။

၅၀ မီတာ = ၀.၀၀၂ မီလီစကၠန္႔
၅ ကီလုိမီတာ = ၀.၀၂၄ မီလီစကၠန္႔
၁၀ ကီလုိမီတာ = ၀.၀၄၈ မီလီစကၠန္႔
၁၀၀၀ ကီလုိမီတာ = ၄.၈ မီလီစကၠန္႔



Propagation Delay and Serialization Delay


R1 နဲ႔ R2 ၾကားက Link ကုိ R2 နဲ႔ R3 ၾကားက Link နဲ႔ ယွဥ္ၾကည့္ရင္ - Bandwidth ပုိမ်ားတဲ့အတြက္ serialization delay တန္ဖုိးနည္းေပမဲ့ distance ကပုိေ၀းတဲ့အတြက္ေၾကာင့္ propagation delay ပုိမ်ားတာကုိ သတိျပဳပါ။

Propagation Delay = Length of Link (in Meters) / 70 % of Speed of Light (i.e. 2.1 x 10^8 meter per second)
Total Propagation Delay = Summation of Propagation at every hop