หากจะพูดถึงหลักการในการทำ Traffic Shaping ใน Linux แล้วนั้น หลาย ๆ ท่านคงทราบดีกว่ามี

• โปรแกรม ชื่อ tc (Traffic Control)
  

  # which tc
  /sbin/tc
  

• ซึ่งเป็นส่วนหนึ่งใน package ชื่อ iproute
  

  # dpkg -l iproute
  ...
  ...
  +++-==============-==============-============================================
  ii  iproute        20090324-1     networking and traffic control tools
  

ที่ช่วยเราจัดการเรื่องนี้ได้ แต่ทว่า การทำ Shaping ของ tc นั้น มีความสามารถจัดการได้อย่างอิสระในฝั่ง egress (ขาส่งข้อมูลออกจาก interface) เท่านั้น ส่วนฝั่ง ingress (ขาส่งข้อมูลเข้า interface) นั้นสามารถทำได้อย่างจำกัด

ถ้ามองในมุมมองของ Clients ที่เรียกข้อมูลเข้ามาที่ Server

• egress (Server) - Downstream ของ Clients (Download)
• ingress (Server) - Upstream ของ Clients (Upload)

ซึ่งจะเห็นว่า ในส่วน Upload อยู่ที่ขา ingress ซึ่งติดข้อจำกัดของระบบ จึงได้เกิดแนวความคิด เรื่องการสร้าง Intermediate Device ขึ้นมา เริ่มต้นที่ได้ทดลอง และใช้งานคือ

• IMQ (Intermediate Queueing Device) ซึ่งได้ทดสอบและใช้งานในช่วงแรก ๆ (ช่วงต้น ๆ ของ Linux 2.6.26) ก็ยังไม่ประสบปัญหาใด ๆ ก็เลยวางใจ จนกระทั้งพบกับปัญหา ที่น่าแปลกตรงที่ว่า เกิดกับเครื่อง IBM เป็นส่วนใหญ่ ซึ่งในระยะหลัง ต้องติดตั้งกับเครื่อง IBM เป็นส่วนใหญ่ จึงได้เริ่มต้นทำการค้นหา ตัวตาย ตัวแทน
• ซึ่งสุดท้าย ก็ได้พบกับ IFB (Intermediate Functional Block) ซึ่งกล่าวอ้างว่า จะเป็นตัวแทน ที่ประสบความสำเร็จกว่า IMQ ซึ่งจากการทดสอบก็เป็นอย่างนั้นจริง ๆ เหตุผลที่น่าสนใจของ IFB คือ มีความชัดเจนว่า สามารถทำงานกับระบบที่มี Multi-Processor ได้เป็นอย่างดี (SMP - Symmetric multiprocessing)

ตัว Intermediate Device เหล่านั้น จะเข้ามาทำหน้าที่เป็นตัวกลาง ในการรับส่งข้อมูล ซึ่งการทำ Shaping ในฝั่งขา ingress ก็จะเปลี่ยนไป คือ จะทำการ redirect ข้อมูล ไปที่ Intermediate Device และหลังจากนั้น ก็ทำการ Shaping ที่ฝั่ง egress ของ Intermediate Device แทน โดยไม่ต้องปรับแก้ Kernel ใด ๆ ทั้งสิ้น ดังแผนภาพ

[============]                      [================]
[  Download  ]<---- (egress shaping)[ eth0 (Server)  ]
[============]                      [================]
                                                                 
[========]             [===============]               [=====================]
[ Upload ]--->(ingress)[ eth0 (server) ]-- redirect -->[ ifb0 (intermediate) ](egress shaping) --->
[========]             [===============]               [=====================] 

ซึ่งเป็นดังนี้ เราก็สามารถที่จะทำ Shaping ได้ตามต้องการ ทั้ง Download และ Upload และก็เข้าตามจุดประสงค์ที่ตั้งใจไว้ของ RahuNAS ที่มีการจำกัดการถ่ายโอนข้อมูลของแต่ละ ผู้ใช้ได้อย่างอิสระ และที่สำคัญคาดว่าการเปลี่ยนมาใช้ IFB น่าจะเพิ่มเสถียรภาพให้ระบบมากขึ้นด้วย