ข่าวส่วนใหญ่มักจะให้ข้อมูลในเรื่องราวที่เกิดขึ้นแล้ว แต่มีข่าวส่วนหนึ่งเล่าเรื่องราวของอนาคต

ข่าวที่ผมกำลังเขียนเป็นเรื่องว่าด้วยอนาคตของ Internet ประเทศไทย มันไม่ใช่อนาคตที่กำลังจะเกิดขึ้น แต่เป็นอนาคตที่เราช่วยกันทำให้มันเกิดขึ้นได้

สืบเนื่องจากข่าวที่แล้ว ผมได้เขียนถึงความไม่ชอบมาพากลของผู้ให้บริการ Internet ในประเทศไทย โดยเขาได้ใช้อำนาจของความเป็นผู้ให้บริการ Internet สับเปลี่ยนข้อมูล เปลี่ยนแปลงการทำงานของเว็บไซต์โดยที่ผู้ใช้งานไม่รู้ตัว และถึงแม้ผมจะไม่เห็นด้วยแต่ผมก็ต้องบอกว่าเขาไม่ได้ทำผิดกฎหมาย (อย่างน้อยๆ ก็เท่าที่ผมรู้นะครับอาจมีส่วนที่ผมไม่รู้ก็ได้) และถ้าคุณคิดจะฟ้องเขาแล้วล่ะก็ คุณอาจโดนทนายค่าตัวแพงของเขาซัดกลับจนหงายหลัง

การเขียนข่าวที่แล้ว ทำให้ผมได้ทำความเข้าใจเรื่องราวมากมาย ขอบคุณความคิดเห็นที่ทุกคนส่งมาอย่างล้นหลาม ผมได้เข้าใจสาเหตุที่ ISP ต้องทำแบบนั้น ผมได้รู้ว่ามีผู้ใช้อีกหลายคนไม่เห็นกับแนวทางการแก้ไขปัญหาในเชิงเทคนิค ที่ผมนำเสนอ (เพื่อให้ Internet โปร่งใสขึ้น) แต่มีคำถามทิ้งท้ายซึ่งเป็นประเด็นที่น่าสนใจที่สุด คือ

เราจะรับมือกับปัญหาดังกล่าวได้อย่างไร?

คำถามนี้เป็นสิ่งที่ผมพยายามคิดหาทางออก ผมรวมทุกอย่างไว้ในสมการความคิดของผม ทั้งเรื่องราวด้านผู้ให้บริการ และผู้ใช้บริการ ปัญหาที่ ISP พบ การตลาด การแข่งขัน ปัญหาของผู้ใช้งาน และผมก็ได้ความคิดหนึ่งคือ เราอาจสร้างมาตรฐาน Internet ของประเทศไทยขึ้นมาเพื่อแก้ไขปัญหาที่เกิดขึ้นแล้วและปัญหาที่อาจเกิดขึ้นได้ แต่ทว่าผมเป็นคนธรรมดาไม่อาจบังคับใช้มาตรฐานใดๆ ได้ ดังนั้นสำหรับวันนี้ ขอให้ได้ฝันก่อนก็ยังดี

ผมเชื่อว่านั่นจะเป็นประโยชน์กับทุกคนนะครับ และถ้าวันนี้ฝนกำลังตกอยู่ ผมคนหนึ่งที่จะทำเรื่องที่ทำได้เพื่อให้ท้องฟ้าวันพรุ่งนี้งดงามกว่าท้องฟ้าใดๆ ที่เคยเห็นมาครับ

เราไปดูในบทความกันดีกว่าว่าผมฝันถึงมาตรฐานอะไรมั่ง

จุดเริ่มต้น: มาตรฐานเพื่อแก้ปัญหาการดัดแปลงแก้ไขข้อมูลโดย ISP โดยมิชอบ

รูปภาพจาก: https://www.owasp.org/
ผู้ให้บริการ Internet หรือ ISP ของเรา กำลังเป็น attacker ดังภาพครับ แต่เขามีเหตุผลในการทำแบบนั้น (หรืออย่างน้อยเขาก็มีข้ออ้างที่ฟังขึ้นในการทำแบบนั้น) นั่นคือการสร้าง cache (รายละเอียดหาอ่านได้ในข่าวเก่านะครับ) และการ block website

ดังนั้นผมจึงเสนอให้มี มาตรฐานในการสร้าง HTTP cache และ มาตรฐานในการ block website ครับ
ผมคิดว่าเราไม่ควร block website ด้วยเหตุผลหนึ่งข้อ คือ เราไม่อาจ block website ได้ตั้งแต่แรกอยู่แล้ว ยกเว้นว่าเราจะ block secure protocol ทั้งหมดเหมือนประเทศจีน (ซึ่งรู้อยู่แล้วว่าไม่อาจทำได้) แต่ผมมีเหตุผลอีกข้อที่ทำให้คิดดูอีกที การ block website ได้ มันก็ดีไปอีกอย่าง คือ ทำเพื่อให้หน่วยงานภาครัฐบางส่วนที่ไม่เข้าใจเรื่องของคอมพิวเตอร์มากนัก สบายใจขึ้นได้ โดยทำให้เขาคิดว่าเขาสามารถ block website ได้ (ซึ่งจริงๆ แล้วทำไม่ได้) สรุปคือมันมีผลทางด้านจิตใจนั่นเอง ดังนั้นการ block website นั้นสำคัญมาก แต่เทคนิคที่นำมา block website รวมถึงเทคนิคที่นำมาใช้สร้าง cache ดันเป็นเทคนิคที่สามารถใช้ในการดัดแปลงแก้ไขหรือบิดเบือนข้อมูลบางส่วนของเว็บไซท์ได้ด้วย การกำหนดมาตรฐานของการทำงานดังกล่าวเพื่อไม่ให้ถูกใช้นอกลู่นอกทางจึงเป็นเรื่องสำคัญ

รายละเอียดการ block website

ผมเสนอให้เราสามารถ block website ได้ด้วย hostname (ข้อมูลที่อยู่ใน Header host: ของ HTTP) เท่านั้น และสามารถใช้ wildcard (*) ในการกำหนดกฎการ block ได้ เพื่อแทนข้อมูลในส่วนของ subdomain เท่านั้น ในกรณีตั้งกฎ block ทุก subdomain เช่น *.example.com ให้ถือเป็นการ block example.com ด้วย
ในกรณีที่ hostname เป็น IP address ห้ามใช้ wildcard ในการตั้งกฎ แต่จะใช้ CIDR notation ในการตั้งกฎแทน สรุปข้อความทั้งหมดเป็นตัวอย่างคือ เราจะเห็นกฎหน้าตาแบบนี้ *.example.com และแบบนี้ 127.0.0.1/16 ถูกตั้งขึ้นเพื่อ block website ต่างๆ ครับ list ของกฎที่ใช้ในการ block website ทั้งหมด ISP และประชาชนทั่วไปต้องสามารถเข้าถึงและตรวจสอบได้

รายละเอียดการสร้าง cache

เรื่องการสร้าง cache นั้น เป็นเรื่องละเอียดอ่อน ไม่ควรปล่อยให้ต่างคน (ต่าง ISP) ต่างทำ (หรืออย่างน้อยต้องสร้างกลไกให้แต่ละ ISP ยันกันเองได้) เพราะผู้รับเคราะห์คือผู้ใช้งานครับ
ในเบื้องต้น ผมเสนอว่าควรกำหนดขึ้นมาว่า cache จะถูกเก็บได้ในกรณีไหนบ้าง โดยตั้งกฎในการเก็บ cache เป็นข้อๆ คล้ายกฎการ block website การตั้งกฎจะยึดตามมาตรฐาน HTTP เป็นหลัก ในทางกลับกันผมก็รู้ด้วยว่า ISP มีปัญหากับ traffic จำพวก Youtube ดังนั้นควรจะเปิดโอกาสให้ ISP เสนอเพิ่มกฎการเก็บ cache ลงไปเองได้ ด้วยเงื่อนไขคือ กฎดังกล่าวต้องมีความแม่นยำ ข้อมูลที่ได้จาก cache ต้องไม่ถูกบิดเบือนไปจากข้อมูลของ server ปลายทาง หรือทำให้การทำงานของ website นั้นๆ ผิดจุดประสงค์ไป และมีกลไกให้ประชาชนทั่วไปสามารถยกเลิกกฎ (หรือปรับปรุงกฎ) ของ cache ได้ ซึ่งจะได้พูดถึงกันต่อไปครับ
ข้อมูลนอกเหนือจากกฎการเก็บ cache ถือว่าไม่สามารถเก็บเป็น cache ได้ ต้อง request จาก server ปลายทางเท่านั้น

ผมเพิ่งจะมาบอกตรงนี้ด้วยชื่อ ordinaryone เป็นครั้งแรก แต่ผมขออ้างถึงตัวเองว่า ผมเขียนโปรแกรมทางด้านระบบเครือข่ายมาตั้งแต่สมัยมัธยม แม้เวลาที่ผ่านมาจะทำเรื่องนั้นเรื่องนี้ที่ไม่ใช่เรื่องเกี่ยวกับระบบเครือข่าย ผมก็มีประสบการณ์มากพอที่จะบอกถึงหลุมพรางต่างๆ ที่อยู่ในระบบ proxy คือ
- HTTP proxy ที่ไม่ได้ออกแบบมาเฉพาะ จะทำ IP address ปลายทางหาย เนื่องจากในการใช้งาน HTTP proxy
URL ของปลายทางทั้งหมด(รวมถึง domain name) จะถูกส่งเป็น URI ของ HTTP proxy แต่ระบบ HTTP proxy ทั่วไปจะไม่มีช่องทางให้ส่ง IP address ทำให้ DNS ถูก proxy server query ใหม่ด้วยตัวเอง หรือมีผลเทียบเท่าการ เปลี่ยน IP address ปลายทาง ทำให้เทคนิคทำเว็บจำพวก roundrobin DNS ทำงานผิดพลาด ปัญหานี้เคยเกิดขึ้นจริงกับเครือข่ายของค่าย "ถูกต้อง" ผมจึงได้โทรคุยเถียงกับพนักงานค่ายนี้ที่ไม่ค่อยรู้เรื่องที่ผมพูดอยู่เป็นชั่วโมง (ปัจจุบันค่ายนี้ได้แก้ไขปัญหานี้แล้ว)
- HTTP proxy จะมี request header ที่เป็น de facto standard ตัวหนึ่งชื่อว่า "X-Forwarded-For" ทำให้ HTTP proxy ที่ไม่ได้ออกแบบมาให้ใช้ร่วมกับเทคนิค IP address spoofing จะใส่ header ตัวนี้ลงไปโดยไม่ได้ตั้งใจ
- HTTP proxy ที่ไม่ได้ออกแบบมาเฉพาะ จะคิดว่า ทุก request ที่ผ่านเข้ามา เป็น HTTP request

จากปัญหาทั้งหมดที่พบใน HTTP proxy ทั่วไป ผมอยากให้คำนึงถึงมาตรฐาน software ที่ใช้ในการ cache ข้อมูลด้วย อย่างน้อยควรมีมาตรฐานดังต่อไปนี้
- ระบบ cache ข้อมูลที่ใช้โดย ISP ห้ามเปลี่ยนแปลง IP address ปลายทางที่กำหนดโดยผู้ใช้
- ระบบ cache ข้อมูลที่ใช้โดย ISP ต้อง spoof IP address เป็นผู้ใช้เพื่อหลอกปลายทาง โดยห้ามแก้ไข HTTP request header ที่ส่งโดยผู้ใช้
- ระบบ cache ข้อมูลที่ใช้โดย ISP จะต้องยอมให้ traffic ที่ไม่ใช่ HTTP ทำงานผ่าน port 80 ได้ด้วย โดยสามารถแยกแยะระหว่าง HTTP traffic และ non-HTTP traffic โดยการตรวจหา request method ของ HTTP โดยในการทำงาน mode non-HTTP traffic จะทำได้โดยการ relay ข้อมูล TCP ทั้งหมด ระหว่างต้นทางและปลายทาง

จุดสำคัญที่เป็นแก่นของมาตรฐานที่ผมคิดขึ้นคือ กลไกตรวจสอบข้อมูลจาก ISP โดยผู้ใช้ เพื่อให้ผู้ใช้สามารถเสนอยกเลิก หรือปรับปรุงกฎการ cache ที่กำหนดขึ้นโดย ISP ได้

ผมขอเสนอ เวทย์มนต์เบื้องหลังหลักการทั้งหมด เป็นคำสัญญาว่าทำไม มันจะทำให้ internet โปร่งใสขึ้น (ไม่ได้โปร่งใสขึ้นทางเทคนิคแต่โปร่งใสในแง่ให้ผู้ใช้มีช่องทางตรวจสอบได้)
ถ้าทำตามมาตรฐานที่ผมเสนอไว้ข้างบนจนถึงตรงนี้ จะเห็นได้ว่าประชาชนทั่วไปสามารถเข้าถึง ข้อมูล blocked websites list และ cache rules list ได้
ใน cache rules list ผมเสนอให้ใส่ ID ที่ใช้ในการอ้างถึงกฎแต่ละข้อไว้ด้วย
ผมขอเสนอให้ HTTP response ที่ไม่ได้ relay จาก server ปลายทางโดยตรง (หรือพูดอีกนัยหนึ่งคือ cache ของ ISP) ใส่ HTTP header พิเศษเพื่อบอกกับผู้ใช้ว่า นี่ไม่ใช่ข้อมูลจากปลายทาง โดย header ที่ผมจะเสนอ มีชื่อว่า "X-Thai-ISP" โดยถ้าข้อมูลมาจาก cache ให้ส่ง header มาประมาณนี้ครับ
X-Thai-ISP: cachehit (#id)
โดย #id จะเป็นเลขหรือข้อมูลที่ใช้ อ้างถึง กฎการ cache ที่ทุกคนสามารถเข้าถึงได้ครับ
เน้นว่าไม่ยุ่งกับ request header แต่นี่เป็นการเปลี่ยนแปลง response header นะครับ
ในกรณีที่ HTTP server ปลายทาง ส่ง header "X-Thai-ISP" มาซะเอง ให้ ISP ลบออก เพื่อป้องกันการโยนความผิดให้ ISP ครับ ในกรณีที่ website ถูก block ให้ส่ง header มาว่า
X-Thai-ISP: blocked (#id)
หลักการอื่นๆ เหมือนกับการ cache ครับ

การเปิดให้คนเปลี่ยนแปลงกฎการ cache ได้ ในช่วงแรกนั้นจะเกิดการโต้เถียงกันมาก แต่ในที่สุดแล้วมันจะเสถียรครับ (ว่าง่ายๆ คือผมไม่ได้คิดมาตรฐานมาเพื่อเป็นผลลัพธ์ทันที แต่ผมคิดมาตรฐานเพื่อให้ลู่เข้าสู่ผลลัพธ์) โดยมีแนวทางการหาข้อยุติในการโต้เถียงตามที่ได้กำหนดไว้แล้วคือ กฎการ cache ทุกกฎต้องมีความแม่นยำ ข้อมูลที่ได้จาก cache ต้องไม่ถูกบิดเบือนไปจากข้อมูลของ server ปลายทาง หรือทำให้การทำงานของ website นั้นๆ ผิดจุดประสงค์ไป ข้อดีอีกข้อของการทำแบบนี้คือ การทำแบบนี้จะช่วยให้ ISP แต่ละเจ้า แทคทีมกันคิดกฎการ cache เพื่อประโยชน์ของทุกฝ่ายครับ รวมถึงจะไม่มี ISP ใดได้เปรียบเสียเปรียบกันที่ cache

สำหรับ ISP ที่คิดจะเล่นตุกติกโดย แอบ cache โดยไม่ส่ง "X-Thai-ISP" header
ผมคิดวิธีเขียนโปรแกรมตรวจสอบไว้เบื้องต้นแล้ว ถ้ามีใครสักคนเอามาตรฐานนี้ไปเป็นฉบับร่างของมาตรฐานจริง อยากให้เตรียมบทลงโทษไว้ด้วยครับ การดัดแปลงข้อมูลต่างๆ ใน website ก็เช่นกัน จะมีผู้ใช้บางส่วนจับได้ (เช่น ผู้ใช้ที่ต่อ VPN ไปต่างประเทศ หรือเช่า VPS มาใช้ SOCKS proxy หรือ SSH proxy เป็นต้น)

มาตรฐานอีกอย่างที่จะไม่พูดถึงไม่ได้เลยเพราะมันจะช่วยแก้ปัญหาการสื่อสารระหว่างผู้ใช้บริการ กับ ISP คือ มาตรฐานการวัดความเร็ว Internet

คือตอนนี้ ตัวเลขที่ โฆษณากันทาง TV 9Mb/s มั่ง 10Mb/s มั่ง มันเป็นความเร็วของ bandwidth ก่อน share (อันนี้อย่างน้อยตามคำอ้างของ ISP นะครับ (ซึ่งน่าจะจริง)) แต่สำหรับผู้ใช้งานแล้ว ไม่มีทางได้ความเร็วดังกล่าวแน่นอนครับ
แต่พูดอีกนัยหนึ่งก็คือ สำหรับผู้ใช้แล้ว ISP จะกำหนดเลขพวกนี้มายังไงก็ได้ ยังไงผู้ใช้ก็ตรวจสอบไม่ได้อยู่แล้ว

ถ้า ISP มีปัญหากับ speedtest.net มากขนาดต้องไปโกงการทำงานของมัน (รายละเอียดหาอ่านได้ในข่าวเก่านะครับ) ผมคิดว่าเราน่าจะพลิกวิกฤตให้เป็นโอกาส โดย เอามันมาวัดความเร็ว Internet ซะเลย
ทำได้ยังไง?
ยกตัวอย่างนะครับเดิมทีหน่วยที่ใช้ในการโฆษณา เป็น 9Mb/s ใช่มั้ยครับ เราจะไม่ใช้หน่วยนี้ในการโฆษณาครับ เราอาจตั้งหน่วยใหม่ขึ้นมา อย่าง "โดริคิ" Internet เร็ว 237 โดริคิ อะไรประมาณนั้นน่ะครับ ยกตัวอย่างเฉยๆ นะ เวลาใช้จริงไม่ใช่อย่างนี้อยู่แล้ว ไอ้หน่วยโดริคิที่ผมยกตัวอย่างนี้ ก็วัดมาจากวิธีการเดียวกับที่ใช้ใน speedtest.net นั้นแหละครับ ถ้ากำหนดมาตรฐานการวัดมาจะมีคนเขียนโปรแกรมวัดให้ตามหลังให้แน่นอนครับ ทีนี้ข้อมูลที่ใช้ในการโฆษณา ต้องให้ ISP ทำการวัดตัวเลขโดริคิเพื่อบ่งบอกความเร็ว Internet ของตัวเอง โดยใช้หลักการทางสถิติ (เช่นการเฉลี่ย) มารวมข้อมูลตัวเลขต่างๆ ให้เหลือเลขเดียว
โดยการเก็บข้อมูลนั้น ต้องคำนึงถึง มิติในการเก็บข้อมูล ขั้นต่ำ 3 มิติ
มิติที่ 1 ตำแหน่งของผู้ใช้ และอัตราการ share bandwidth ในตำแหน่งที่เก็บข้อมูลครับ
มิติที่ 2 ตำแหน่งของ web server เช่นอยู่ที่ประเทศอะไร ทวีปไหน เป็นต้น
มิติที่ 3 มิติเวลาที่ใช้ในการเก็บข้อมูลครับ
พอเก็บข้อมูลได้ครบทุกมิติ ค่อยทำการเฉลี่ย (หรือการดำเนินการทางสถิติอื่นๆ) ทำให้ข้อมูลความเร็ว Internet ที่กระจายอยู่ในทุกมิติ รวมกันเป็นหน่วยโดริคิเพื่อใช้ในการโฆษณาครับ นอกจากจะเป็นความเร็วที่ตรวจสอบได้แล้ว ยังช่วยให้ผู้ใช้งาน เข้าใจ ISP มากขึ้นด้วย

อีกเรื่องเกี่ยวกับระบบเครือข่าย ที่อยากให้กำหนดแนวทางการปฏิบัติ

เรื่องนี้ไม่จำเป็นต้องบังคับหรือกำหนดเป็นมาตรฐานนะครับ แต่อยากให้กำหนดเป็นแนวทางการปฏิบัติคือ เรื่องช่องสัญญาณ Wi-Fi ครับ ผมจะไม่อธิบายแบบเข้าใจง่ายไว้ในข่าวนี้นะครับ ถ้าใครคิดว่าอธิบายแบบง่ายๆ ได้ ช่วยเขียนใหม่ทีนะ
คือสัญญาณ Wi-Fi ที่เราใช้กันอยู่นั้น ถ้าไปซื้อเสาสัญญาณ เราอาจจะเห็นว่ามันเขียนข้างกล่องว่า 2.4 GHz ซึ่งเป็นจุดเพียงจุดหนึ่งของความถี่เท่านั้นครับ เหมือนเวลาเรามองไม้บรรทัดแล้วเราดูที่จุด 2.4 cm นั่นแหละ มันเป็นแค่จุดๆ หนึ่งไม่มีระยะ แต่สิ่งที่เราต้องการในการส่งสัญญาณ Wi-Fi คือ bandwidth หรือก็คือ ช่วงของความถี่ครับ หรือถ้าคุณผู้อ่านกำลังมองไม้บรรทัดอยู่จริงๆ มันก็เปรียบเทียบได้กับระยะเช่น 5 mm บนไม้บรรทัด มันอาจจะเป็นระยะจากจุด 5.5 cm ถึง 6.0 cm หรือ จากจุด 6.2 cm ถึง 6.7 cm หรืออาจเป็นระยะ 5 mm ในส่วนอื่นๆ ของไม้บรรทัดก็ได้
เวลาเรา config router มันจะมีส่วนที่ให้เราใส่ channel ด้วยนะครับ อาจจะมีช่อง 1 ถึง 11 หรือ 1 ถึง 13 ให้เลือกก็แล้วแต่ยี่ห้อแล้วแต่รุ่นนะครับ ปัญหามันอยู่ตรงนี้ครับ คือ เราจะเลือกช่องไหนให้ถูกสัญญาณจากเพื่อนบ้านกวนน้อยที่สุด หรือ router เราไปกวนสัญญาณเพื่อนบ้านน้อยที่สุด การที่เราจะเลือกได้นั้นเราต้องเข้าใจก่อนว่าแต่ละช่องสัญญาณ มี bandwidth หรือระยะที่ทับกันครับ เช่น ช่อง 1 อาจจะเป็นจุด 0 ถึง 4 cm บนไม้บรรทัด ช่อง 2 อาจจะเป็น 1 ถึง 5 cm บนไม้บรรทัด ไล่ไปจนถึงช่อง 13 ซึ่งอาจถูกมองเป็น ระยะจากจุด 12 cm ถึง 16 cm บนไม้บรรทัดครับ การเลือกให้ไม่ถูกสัญญาณรบกวนคือการเลือกช่องที่ bandwidth ไม่ทับกับของคนอื่น เช่น มี router 3 เครื่อง ตั้งใกล้กัน ถ้ามันถูกตั้งค่าเป็นช่อง 1, 6, 11 ทั้งสามเครื่องก็จะทำงานได้อิสระจากกัน (ไม่ถูกเครื่องอื่นกวน) แล้วถ้ามีเครื่องที่สี่เข้ามาล่ะทำไง? หลายคนจะคิดว่าเราควรใช้ช่องที่ไม่มีคนใช้ เช่นช่อง 2, 3, 4 อะไรเทือกนี้ครับ แต่จริงๆ แล้วพลาด เราควรเลือก 1 ในสามความถี่ที่คนใช้อยู่ครับโดยดูว่าสัญญาณของ router เครื่องอื่น ความถี่ช่องไหน weak ที่สุดครับ

เกิดอะไรขึ้นถ้าเราเลือกช่อง 2?
อย่างที่บอก ถ้าช่อง 1 คือ 0 ถึง 4 cm ช่อง 2 คือ 1 ถึง 5 cm ทำให้ bandwidth เกิดการเหลื่อมกันครับ การเหลื่อมทางความถี่ดังกล่าวทำให้ router แบ่งเวลากันทำงานไม่ได้ แต่ถ้าใช้ความถี่เดียวกันไปเลยมันจะมี MAC layer เข้ามาจัดการแบ่งเวลากันทำงานครับ (พวก CSMA อะไรเทือกนั้น) US ก็ใช้ความถี่ ช่อง 1, 6, 11 เป็นมาตรฐานมานานตั้งแต่ 802.11b (เขาเลือก 3 ช่องนี้เพราะเป็นความถี่ที่ชิดที่สุดที่ไม่เหลื่อมกันใน b) พอเป็น g แล้วก็ยังใช้ได้ (แม้ g จะใช้ bandwidth แคบกว่า b) แต่พอมาถึงยุคของ n (ซึ่งแต่ละช่องมีขนาดเท่าช่องของ g) n คิดวิธีใช้ช่องคู่ที่อยู่ติดกันเพื่อเพิ่มความเร็วการส่งข้อมูล เช่นใช้ช่อง 1 กับช่อง 5 พร้อมกันเป็นต้น (หรือถ้ามองในไม้บรรทัดก็คือช่วง 0 ถึง 8 cm) ทำให้ เจ้า 1, 6, 11 นี่ชักไม่ค่อย work แล้ว น่าจะใช้ช่อง 1, 5, 9, 13 มากกว่า (ในกรณีแถวนั้นไม่มี router 802.11b) แต่ว่าแถวบ้านผมตั้งช่องกันมั่วนิ่มมาก ถ้ามีแนวทางปฏิบัติหน่อยก็คงดีกว่านี้

มาตรฐานทั้งหมดทั้งมวลที่ผมยกขึ้นมานี้ ยังไม่ถูกใช้จริง และมีโอกาสที่จะไม่มีวันถูกใช้จริง แต่ถ้าคุณคิดว่าเป็นมาตรฐานที่ดี หรืออย่างน้อยก็มีส่วนหนึ่งที่ดี หรือเป็นจุดเริ่มต้นที่ดี คุณช่วยได้ดังนี้ครับ

• หาจุดอ่อนในมาตรฐานนี้ หรือควรมีอะไรเพิ่มเติม อยากให้ comment ทิ้งไว้ครับ (สมมุติเล่นๆ ว่าเราสามารถร่างมาตรฐานได้เอง ((อย่างน้อย) ขอให้ได้ฝัน))
• share ไปให้ไกลที่สุด เผื่อว่าโอกาส 1 ในล้าน จะมีใครสักคนที่มีอำนาจบังคับใช้ ได้อ่านเข้า
• ถ้าคุณเป็นคนหนึ่งที่นำเรื่องเข้าสู่การดำเนินการอย่างเป็นทางการได้ ขอให้พิจารณาเรื่องนี้ด้วยนะครับ

แนวทางการกำหนดมาตรฐานนี้ เป็นเพียงแนวทางหนึ่งในการแก้ปัญหาที่พบในข่าวเก่า ซึ่งนี่เป็นคำตอบของผมครับ อาจมีคำตอบอื่นที่นอกเหนือจากแนวทางนี้ อาจมีวิธีการอื่นที่ไม่จำเป็นต้องถูกกำหนดเป็นมาตรฐานก็สามารถนำไปใช้ได้ และถ้าคุณคิดวิธีการนั้นออก นั่นก็เป็นคำตอบของคุณครับ อย่าเก็บคำตอบของคุณไว้คนเดียว ลองเขียนให้คนอื่นอ่านด้วยก็จะดีมากเลยครับ

สวัสดีครับ