در جستجوی اینترنت و وب سایتی سریع تر و عادلانه تر

در جستجوی اینترنت وب سایتی سریع تر و عادلانه تر

پروتکل TCP (روشی که بر اساس آن عرض باند اینترنت را بهاشتراک می گذاریم) نیاز به بازسازی مجدد دارد.

اینترنت بر پایه یک منطق ساده بنا شده است: لینکهای ارتباطی اشتراکی،کارآمدتر از کانالهای اختصاصی هستند که در اکثر مواقع بیکار می مانند.ما شبکه هایمحلی را در محل کار و لینکهای نزدیک را در منزل به اشتراک می گذاریم. در هر زمانمعین، یک کابل Backbone ترابایتی در میان هزاران کاربری که در حال گردشدر وب، بارگذاری ویدیوها و مکالمه بر روی تلفنهای اینترنتی هستند به اشتراک گذاشتهمی شود. با اینحال یک نقیصه عمیق در پروتکلی که بر نحوه به اشتراک گذاری ظرفیتاینترنت در بین مردم نظارت می کند، وجود دارد. این پروتکل به شما اجازه می دهد کهمودب به نظر برسید، حتی زمانیکه دیگران را کنار زده و منابع بسیار بیشتری را درمقایسه با آنها اشغال می کنید.

تامین کنندگان شبکه نظیر Verizon و BTبا ظرفیت بیشتری را برای حل این مشکل تامین کرده و یا فرمولهایی را تعبیه می سازندکه تلاش می کنند مشکل " غاصبین باند" را جبران نمایند. اجازه بدهید همینحالا تکلیف این گروه بدنام را روشن کنیم: مشکل اصلاً به غاصبین پهنای باند مربوطنمی شود. مادامیکه مشتریان ما باعث نشده اند که سایر کاربران با کمبود پهنای باندمواجه گردند، هیچ نیازی نیست که از بارگذاری حجمهای عظیمی از داده ها توسط آنهاجلوگیری کنیم.

بجای دور زدن مشکل، Bob Briscoe و همکارانش در BT( که سابقاً با عنوان British Telecom شناخته می شد) بر روی حل عامل ریشه ای این مشکلکار کردند: خود پروتکل اشتراک گذاری اینترنت، بعداً مشخص شد که این راه حل نه تنهااینترنت را ساده تر خواهد نمود، بلکه سرعت آن را نیز افزایش خواهد داد.

شاید شگفت زده شوید اما طراحان اینترنت ترتیبی داده اند تا سهم شما ازظرفیت اینترنت بر حسب مقداری که توسط نرم افزار خودتان عادلانه در نظر گرفته میشود، تعیین گردد. آنها هیچ نقش میانجی گرانه ای را ما بین نیازهای در تقابل مصرفکنندگان عرض باند اینترنت (در حال حاضر، یک میلیارد کامپیوتر شخصی، ابزارهایموبایل و سرورهای متعدد) برای اپراتورهای شبکه بازی نمی کنند.

الگوریتم اصلی اشتراک گذاری اینترنت ، TCP(Transmission Control Protocol) تعبیه شده است، یک روتین بر روی کامپیوترخودتان که اکثر برنامه ها آن را اجرا می کنند، هر چند که مجبور به انجام اینکارنیستند. TCP یکی از ستونهای دوقلوی اینترنت به حساب می آیدو ستون دیگر نیز همان پروتکل اینترنت(IP) است که بسته هایداده را به آدرسهای بخصوصی تحویل می دهد. این دو پروتکل در کنار یکدیگر غالباً تحتعنوان TCP/IP شناخته می شوند.

روتین TCP دائماً نرخ انتقال شما را افزایش می دهد، تازمانیکه بسته ها در عبور از یک لوله بالاتر ناکام بمانند(یک نشانه هشدار دهنده ازانسداد). سپس، TCP بصورت بسیار مودبانه ای نرخ بیت شما را نصف میکند. میلیاردها روتین TCP دیگر در سراسر اینترنت درست به همین شکل همل میکنند: در یک چرخه گرفتن و سپس آزادسازی پهنای باند که لوله های ارتباطی را پر کردهو در عین حال آنها را به طور یکسانی به اشتراک می گذارد. این یک نمایش خارق العادهجهانی از تواضع و تعارف است، درست همانند پروتکل "بعد از شما" که دو نفروقتی همزمان به یک درب می رسند از آن استفاده می کنند. اما در یک وضعیت بی معنی،نسخه اینترنتی این تعارف مابین دو طرف کاملاً بیگانه(حتی دو رقیب تجاری کینه توز)و آنهم میلیاردها بار در ثانیه روی می دهد.

تلاشهای تجاری به سختی می توانند بالاتر از این باشند. سرویسهایی نظیرYouTube , eBay , Skype و iTunes همگی بر اساس مقدارظرفیت اینترنتی که می توانند برای شما جذب کنند قضاوت می شوند. تلفن اینترنتی وسرویسهای تلویزیونی که توسط خود Carrierها تامین می شوند نیز وضعیت مشابهی دارند. بعضی از این شرکت ها تصمیمگرفته اند که رژیم اشتراک گذاری TCP را کنار بگذارند اما اکثر آنها هنوز به TCPاجازه می دهند که میزان پهنای باند دریافت شده توسط آنها را کنترل نماید: نزدیک به90درصد از 200000 ترابایتی که در هر ثانیه بر روی اینترنت جابجا می شود.

ترکیب استفاده جهانی و تایید آکادمیک به تدریج باعث گردید تا شیوه TCPدر اشتراک گذاری ظرفیت به یک جایگاه رفیع اخلاقی دست یافته و زبان مورد استفادهمهندسین را تغییر دهد. از ابتدا، نرخهای یکسان، واقعاً " یکسان" نبودندبلکه " عادلانه" به حساب می آمدند. حتی اگز ار TCPاستفاده نمی کنید، در صورتیکه پروتکل شما " TCP-Fiendly  "نباشد ( یک ایده راحت، به این معنی که تقریباً از همان نرخ بیت TCPاستفاده می کند)، مشکوک در نظر گرفته خواهد شد.

یک شبکه Neighborhood را با 100مشتری در نظر بگیرید که هر یک از آنهادارای یک خط دسترسی 2 مگابیت بر ثانیه ای متصل به یک لینک منطقه ای 10 مگابیت برثانیه ای منفرد و اشتراکی می باشند. تامین کننده شبکه می تواند کار خود را با چنینلوله اشتراکی باریکی آغاز کند زیرا اکثر مشتریان(فرض کنیم 80 نفر از مشتری) بطوردائمی از آن استفاده نمی کنند، حتی در زمانهای اوج مصرف. این افراد احتمالاً فکرمی کنند که دائماً در حال کلیک در مرورگرهای خود و دریافت e-Mailهای جدید هستند، اما انتقال داده های آنهامی تواند تنها برای 5 درصد از کل زمان فعال باشد.

با اینحال، هنوز 20 کاربر سنگین نیز وجود دارند که دائماً مشغولبارگذاری فایلهای سنگین هستند و احتمالاً از برنامه های اشتراک گذاری فایل استفادهمی کنند که بدون هیچ مراقبتی اجرا می شوند. بنابراین  در هر لحظه، داده ها تقریباً برای 24 کاربرجریان دارند(20 کاربر سنگین و 4 کاربر از 80مشتری سبک). TCPبیست سهم از ظرفیت گلوگاه را به کاربران سنگین و تنها 4 سهم را به کاربران سبکاختصاص می دهد. در طول چند لحظه، 4 کاربر سبک کنار رفته و سهم خود را به 4 کاربردیگر واگذار می کنند. با اینحال، 20کاربر سنگین هنوز حضور دارند و 20 سهم بعدی خودرا طلب می نمایند. ممکن است آنها مدارهای اختصاصی نیز داشته باشند.

وضعیت می تواند بدتر از این باشد. هر برنامه نویس می تواند روتین TCPرا چندین بار اجرا کرده و سهم های متعددی را بدست آورد. وضعیت مذکور درست ماننداین است که یک سیستم جیره بندی غذا را با کپی کردن کوپنهای جیره بندی، دور بزنید.

تعدادی از استراتژیهای مشابه، از طریق آزمایشها و تجربیات بی ضرر وساده ای رشد کردند. اشتراک گذاری فایل Peer-to-Peer (P2P) را در نظر بگیرید،یک شیوه تبادل فیلم بر روی اینترنت که بخش عمده ای از کل ترافیک را به خود اختصاصمی دهد. این روش شامل بارگذاری یک فایل از چند Peerمختلف بطور همزمان است. این الگوی موازی که گاهی اوقات تحت عنوان " حرکت گلهای" (Awarming) شناخته می شود، در سال 2001 به یک جریان عادیتبدیل شد و نهایتاً در پروتکلهایی نظیر BitTorrent پیاده سازی گردید.

جامعه شبکه سازی، بلافاصله برقراری ارتباط با چندین ماشین را بعنوانیک حیله برای دور زدن از TCP استفاده می کرد و به همین دلیل هر جریان داده" بطور صحیح" یک سهم از گلوگاهی که اشغال می کرد را دریافت می نمود. امااستفاده از ارتباطات موازی برای ماشینهای متعدد، سطح تازه ای از آزادی بود که وقتیقواعد برای اولین بار نوشته می شدند، مورد توجه قرار نگرفته بود. عدالت بایدبعنوان یک رابطه در بین انسانها تعریف شود، نه جریانهای داده.

اشتراک گذاری فایل Peer-to-Peer هر دو نقیصه TCPرا آشکار کرد. ابتدا، یک برنامه اشتراک گذاری فایل می توانست 20 برابر بیشتر ازمرورگر وب شما فعال باشد و دوم اینکه این برنامه از ارتباطات TCPبسیار بیشتری استفاده می کند (معمولاً 5 یا حتی 50برابر). بنابراین 100 P2Pیا 1000برابر سهمی را از گلوگاه های اینترنتی دریافت خواهد کرد که یک مرورگر بدستمی آورد.

Throttling

Throttling تلاش می کند تا سیستم TCPامروزی را با محدودسازی کاربران سنگین برطرف نماید. اما این تکنیک فاقد عملکردهوشمندان است. با اشتراک گذاری توزین شده TCP کاربران سبک میتوانند فوق العاده  سریع باشند که در نتیجهکار انها زودتر به اتمام خواهد رسید. در عین حال ، سرعت کاربران سنگین نیز تنهااندکی کاهش خواهد یافت و سپس مجدداً افزایش می یابد. تمام این کار بدون اعمالهرگونه اولویت بندی در شبکه قابل انجام است.

چرا تامین کننده سرویس نمی تواند به سادگی این لوله 10 مگابیت برثانیه ای باریک خود را ارتقاء دهد؟ البته، گهگاه بعضی از ارتقائها ضرورت پیدا میکنند. اما بعنوان یک راه حل کلی برای مشکل اشتراک گذاری، اضافه کردن ظرفیت درستمانند آن است که آب را به سمت بالا پرتاب کنیم.

دو تامین کننده سرویس اینترنت را د رنظر بگیرید که هر دو آنها با یکترکیب "20 به 80 " از کاربران سنگین و سبک مواجه هستن. یک تامین کنندهظرفیت خود را 4 برابر می کند اما تامین کننده دیگر تغییر در ظرفیت نمی دهد. بااینحال، TCP هنوز ظرفیت ارتقاء یافته را به همان ترتیبتقسیم خواهد کرد. بنابراین کاربران سبک که به در اختیار داشتن یک سهم ناچیز 20کیلو بین بر ثانیه ای عادت کرده اند، اکنون یک سهم ناچیز 80کیلوبیت بر ثانیه ای رادریافت می نمایند که هنوز چندان بهتر از یک اتصال Dial-upبه نظر نمی رسد. اما اکنون 80کاربر سبک باید هزینه بسیار بیشتری را برای 4 برابرظرفیت دوربرد( که به سختی از آن استفاده می کنند) بپردازند. هیچ اپراتور شبکهمعقولی در این شرایط ظرفیت خود را ارتقاء نخواهد داد، زیرا به این ترتیب اکثرمشتریان خود را ازدست می دهد.

تامین کنندگان شبکه غالباً به TCP اجازه نمیدهندکه تمام ظرفیت جدید را مستقیماً در اختیار کاربران سنگین بگذارد. در مقابل،آنها رژیمهای اشتراک گذاری خود را برای مشتریانشان پیاده سازی نموده و در نتیجهبدترین تاثیرات رژیم شکسته TCP را حذف می کنند. بعضی از آنها، نرخ بیت مشتریانP2P را در ساعات اوج مصرف محدود مینمایند. گروه دیگری از تامین کنندگان، لوله را برای جلوگیری از غصب سهم کاربرانسبک تر نوسط کاربران سنگین، تقسیم بندی می کنند. سهم ظرفیت اینترنتی که شما عملاًدریافت می کنیدبطور فزاینده ای نتیجه این نزاع میان TCPو الگوهای واگذاری تامین کنندگان سرویس است.

یک راه حل بسیار بهتر از رویکرد مبارزه وجود دارد. این روش به یکفرایند مرور سبک اینترنت اجازه می دهد که با سرعت بسیار بالایی انجام شود، امااصلاً باعث طولانی شدن بارگذاریهای سنگین نخواهد گردید. راه حل مورد نظر از دو بخشتشکیل شده است. روش مذکور با آسانتر نمودن اجراهای متعدد TCPبرای برنامه نویسان آغاز می شود.

برنامه نویسانی که از این پروتکل جدید برای انتقال داده ها استفاده میکنند، می توانند بگویند که "مانند 12 جریان TCPرفتار کن " و یا " مانند %25 یک جریان TCPرفتار کن". آنها یک پارامتر(یک وزن) جدید را بصورتی تنظیم می  کنند که هرگاه داده های شما با  داده های دیگری مواجه شود که همگی برای عبور ازیک گلوگاه واحد تلاش می کنند، شما (برای مثال) 12 سهم و یا یک چهارم یک سهم رابدست خواهید آورد. به یاد داشته باشید که شبکه این اولویتها را تعیین نمی کند. اینروتین جدید TCP در کامپیوتر خودتان است که از این وزنها برایکنترل تعداد سهم هایی که از شبکه می گیرد، استفاده می کند.

کلید این موضوع در تنظیم نمودن وزن بالا برای استفاده های تعاملی سبکنظیر مرور وب و وزن پایین برای کاربردهای سنگین نظیر بارگذاری یک فیلم است. هر گاهکه این مصارف با یکدیگر برخورد کنند، جریان دارای وزن بالاتر (متعلق به کاربرانسبک) سریعتر حرکت خواهد کردو این بدان معنی است که بسیار زودتر نیز تمام خواهد شد.سپس، جریان سنگین مجدداً می تواند به یک نرخ بیت بالاتر برگردد. به همین دلیل استکه اتمام جریانهای سنگین، طولانی تر نخواهد شد. الگوی توزین از همان استراتژی یکمدیر رستوران استفاده می کند که می گوید: " سفارش همه مشتریان را بگیرید، سپسبه این جشن 12 نفره برسید". اما اینترنت امروزی وزنها را بطور دقیق با شیوهدیگری متعادل کرده است.

این وضعیت ما را به دومین بخش از مشکل هدایت می کند: چگونه می توانیمهر کاربر را به کاهش وزن ترغیب نمائیم؟ این کار به معنای درگیر شدن با چیزی است کهغالباً تحت عنوان " تراژدی توده ها " شناخته می شود. یک مثال آشنا ازاین وضعیت، گرم شدن کره زمین است که در آن هر انسان بر روی کره زمین با خوشحالیرفتار دلخواه خود را دنبال می کند(چراغها را روشن می گذارد، ماشینهای بزرگی را میراند) علیرغم آنکه رفتارش به خاطر ایجاد دی اکسید کربن و سایر گازهای گلخانه  ای برای هر انسان دیگری بر روی کره زمان نتایجمنفی به همراه خواهد داشت.

بر روی اینترنت، چیزی که اهمیت دارد این نیست که شما چند گیگابایتبارگذاری می کنید، بلکه این است که وقتی افراد دیگری نیز تلاش می کنند همین کار راانجام دهند، چقدر بارگذاری می کنید. بطور دقیق تر، این حجمی که شما بارگذاری میکنید نسبت به سطح عمومی تراکم شبکه است. اجازه بدهید این گزینه را حجم تراکم (Congestion Volume) بنامیم که بر حسب بایت اندازه گیری می شود.شما می توانید آن را بعنوان ردپای کربنی استفاده خود از اینترنت در نظر بگیرید.

همانند CO2، شیوه کاهش، همان تعیین محدوده ها است. دنیاییرا تصور کنید که در آن چند تامین کننده سرویس اینترنت  یک قرارداد با قیمت ثابت اما با یک سهمیه حجمتراکم ماهیانه ارائه می نماید. توجه داشته باشید که این سهمیه، میزان بارگذاریهایشما را محدود نمی کند بلکه تنها مواردی که در طول تراکم و انسداد شبکه پافشاری مینمایند را محدود خواهد کرد. اگر از یک برنامه P2Pنظیر BitTorrent برای بارگذاری همزمان 10 ویدیو استفاده میکردید، برای آنکه سهمیه تان به سرعت به اتمام نرسد باید وزنTCPخود را به اندازه کافی پایین می آوردید. در طول لحظات کوتاهی که جریانهایی باوزنهای بالاتر از راه می رسند، بارگذاریهای شما عقب نشینی می کنند. اما در انتها،بارگذاری ویدیوهای مورد نظرتان به سختی بیشتری از وضعیت امروزی آنها طول خواهندکشید.

از سوی دیگر، مرورگر وب شما باید وزن را برای تمام کارهای مروری خودبالا تنظیم کند، زیرا اکثر کارهای مروری با عجله زیادی همراه هستند و در عین حالمقدار زیادی از سهمیه مار ا مصرف نمی کنند. البته، Server-Farmها یا کاربران سنگین می توانند سهمیه تراکمبزرگتری را خریداری کنند و کاربران سبک نیز احتمالاً با یک سهمیه تراکم کوچک(کههزینه ثابت پایین تری نیز خواهد داشت)به اینترنت دسترسی پیدا می کنند.

اما در اینجا یک مانع وجود دارد تامین کنندگان امروزی سرویس اینترنتنمی توانند محدودیتهای تراکمی را ایجاد کنند زیرا تراکم می تواند به آسانی از چشمآنها پنهان بماند. همانطور که قبلاً نیز اشاره کردیم قرار بود تراکم اینترنتانحصاراً توسط کامپیوترهایی که در حاشیه آن قرار گرفته اند مدیریت و شناسایی گردد،نه توسط تامین کنندگان سرویس در مرکز آن، بدیهی است که گیرنده پیامهای Feedbackمرتبط با تراکم را برای فرستنده ارسال می نماید که شبکه قادر به مشاهده آنها میباشد. اما وضعیت گیرنده را ترغیب می کند که Feedbackرا مخفی کرده و یا گزارشهای نادرستی را در ان ارسال نماید. به هر حال شما مجبورنیستید چیزی را فاش کنید که میتواند بعنوان مدرک بر علیه خودتان مورد استفاده قرارگیرد.

Bob Briscoe و همکارانش شیوه ای را پیدا کردند تا تراکم رابه گونه ای که امکان اعمال محدودیتها فراهم گردد، آشکار نمایند. آنها روش خود را "refeedback" نامیدند. نحوه کارروش مذکور به این ترتیب است: به یاد بیاورید که امروزه کامپیوترها در دو انتهای یکمسیر تبادل بسته ها، تراکم را مشاهده می کنند اما شبکه های مابین آنها قادر بهمشاهده نیستند. بنابراین، آنها روش خود را بر اساس تکنیکی با نام Explicit Congestion Notification بنا کردند یعنی آخرین تغییر بر روی استانداردTCP/IPکه در سال 2001 اعمال گردید. تجهیزاتی که این تغییر را پیاده سازی می کنند، بستهها را در طول یک انسداد قریب الوقوع علامتگذاری می کنند (بجای آنکه هیچ کاری انجامندهند تا نهایتاً مجبور به از قلم انداختن آنها شوند). نشانه ها ( که تنها یکتغییر در یک بیت واحد هستند) به شبکه اجازه می دهند تا مستقیماً تراکم را مشاهدهکند، نه اینکه آن را از فواصل موجود در جریان بسته ها استنباط نماید. این روش بسیارمناسب است زیرا امکان محدود سازی تراکم را پیش از آنکه هیچ اختلال واقعی را برای کاربریبه همراه داشته باشد، فراهم می سازد.

Refeedback یک نوع ثانویه از علامتگذاری بسته ها را معرفیمیکند. شما می توانید آن را بصورت اعتبار و نشانه گذاریهای اولیه تراکم را بعنوان بدهیدر نظر بگیرید. فرستنده باید اعتبار کافی را به بسته هایی که وارد شبکه می شونداضافه نماید تا علامتهای بدهی که با ورود بسته ها به لوله های متراکم اینترنت بهآن اضافه می شوند را بپوشاند. اگر هر گروه بعدی شبکه تشخیص دهد که نسبت اعتبار بهبدهی کافی نیست، بسته های جریان مختلف را نادیده می گیرد.

برای رفع این مشکل، هربار که گیرنده یک نشانه تراکم(بدهی) را می گیرد،Feedbackرا به فرستنده بر میگرداند. سپس فرستنده بسته بعدی را با یک اعتبار علامتگذاری می کند. سپس این Feedbackمجدداً درج شده یا همان Refeedback می تواند در محل ورود به اینترنت برای محدودنمودن تراکم مورد استفاده قرار گیرد( شما " باید " هر چیزی که می تواندبعنوان مدرک برعلیه خودتان مورد استفاده قرار گیرد را فاش کنید).

اضافه نمودن محدودیتها و بررسیهای مربوط به انسداد در حاشیه هایاینترنت برای هر اپراتور شبکه کاملاً آسان خواهد بود. غیر از این الگوی Refeedback نیازی به اضافه شدن هیچ کد جدیدی به تجهیزاتشبکه ندارد. تمام کاری که باید انجام شود، فعال سازی اخطار انسداد استاندارد است.اما بسته ها به جایی برای حمل نشانه دوم در بخش "IP" فرمول TCP/IP نیاز دارند.خوشبختانه این نشانه گذاری امکانپذیر است زیرا یک بیت بلا استفاده در انتهای هدرهر بسته IP وجود دارد.

در این نقطه، داستان تا حدودی شخص می شود زیرا Briscoeمجبور بود وظیفه خود در زمینه به چالش کشیدن اصل نقض شده " TCP- Friendliness" (یکسانی نرخهای جریان برای تمام ارتباطاتTCP) را کنار بگذارد. او تصمیم گرفت تنها دربارهتغییر IP صحبت کرده و از هر اشاره ای به TCPتوزین شد خودداری نماید. در مقابل، او انگیزه دیگری را برای اضافه کردن refeedback به IP پیدا کرد. اوحتینشان داد که refeedback چگونه می تواند نرخهای جریان یکسان را اعمالکند. با اینحال او هنوز به یک محقق دیوانه دیگر شبیه بود که یک راه حل را برایمشکلی که وجود نداشت ارائه می کرد.

پس از یکسال، او یک حمله خشمگینانه(اما به اعتقاد خودش دقیق) را برعلیه این اعتقاد متعصبانه که نرخهای جریان یکسان " عادلانه " هستند،نوشت. همکارانش او را وادار کردند تا پیش از ارسال نوشته مذکور به IETF،آن را تعدیل نماید. ظاهراً او نوشته خود را به اندازه کافی تعدیل کرد تا حداقلبرای ارائه ایده هایش در نشست جامعی که اواخر سال 2006 در سان دیگو برگزار میگردید، دعوت شود. روز بعد، نظرات جمع بزرگ حاضرین در این نشست، یک تردید گسترده رادرباره استفاده از TCP- Friendliness"" بعنوان یکتعریف برای " عدالت" نشان می داد. Elwyn Davies از InternetArchitecture Boardدر یک eMail برای او نوشت " شما یک ترکیب واقعی ازنزدیک بینی را در IETF شناسایی کرده اید".

Briscoeبه هیچ وجه اولین شخصی نبود که به مبارزه با این اسطوره ها می پرداخت. در 1997، Frank p.Kelly یک استاد دانشگاه کمبریج نیز یک استدلال ریاضیموجز و فوق العاده هوشمندانه را برای اثبات این موضوع که همین اشتراک گذاری توزینشده می تواند ارزشی که کاربران از توان عبوردهی اینترنت خود بدست می آورند را بهحداکثر برساند، ارائه نمود. با اینحال، او برای ایجاد انگیزه های مناسب پیشنهادکرده بود که قیمتهای  متغیری برای بسته هادر هنگام دریافت آنها تعیین شود و همچنین مسئله باعث شد که همه ایده او را ردکنند. مردم دوست دارند آنچه که پرداخت خواهند کرد را از قبل کنترل کنند.

مخالفتهای انجام شده با الگوی قیمت گذاری Kelly،چشمان جامعه اینترنت را بر روی هر درون بینی دیگری در کارهای او (خصوصاً این پیامکه یکسان سازی نرخ جریان یک هدف مطلوب  بهحساب نمی آید) بست. به همین دلیل بود که تیم Briscoeمکانیزم refeedback را بر اساس ایده های قبلی او(محدود سازی انسداددر هزینه های ثابت، بدون قیمت گذاری دینامیک) پایه گذاری کردند.

وسواس فکری عمومی در مورد Bandwidth – Hogها و در نتیجه حجم نیز کاملاً اشتباه می باشد. چیزی که واقعاً اهمیتدارد، حجم تراکم و یا همان CO2 اینترنتی است.