Rezydując poza siecią wewnętrzną, WiseWan może obsługiwać strumienie ruchu wchodzące do sieci. Ujemną stroną takiego umiejscowienia jest mała kontrola nad ruchem wewnętrznym w sieci.

Regulatory ruchu klasy reprezentowanej przez PacketShaper są umiejscawiane wewnątrz sieci prywatnej - tuż za routerem. PacketShaper przechwytuje potwierdzenia TCP w wchodzących strumieniach danych i decyduje o tym, na jaki czas wstrzymać takie potwierdzenie. Reguluje w ten sposób opóźnienia potwierdzenia odbioru, a tym samym i tempo przesyłania pakietów danych. W tym celu regulator ruchu sięga do pakietów TCP/IP, identyfikuje aplikacyjny typ ruchu i określoną parę adresów IP, a następnie rozdysponowuje pasmo według tych parametrów.

Proces ten działa jak regulator dozujący: ruch dławiony jest przez urządzenie transmitujące, otwierające pasmo dla typów ruchu o wysokim priorytecie. Ponieważ PacketShaper nie buforuje ruchu jak WiseWan, jeżeli zdarzy się natłok, program oblicza opóźnienie obowiązujące aż do jego ustąpienia i rozdziela zgodnie z tym pasmo. Jedną z korzyści, jakie daje regulator pakietów umiejscowiony po wewnętrznej stronie sieci, jest możliwość zastosowania reguł decyzyjnych do lokalnego ruchu sesji TCP.

Oba typy produktów należą do tej samej kategorii urządzeń, ale działają w całkowicie odmienny sposób.

Rozwiązania typu WiseWan 200 powinny być używane w zarządzaniu łączami dostępowymi WAN do ośrodków webowych leżącymi pomiędzy routerem i ISP. Ponadto jeżeli jest potrzebna kompresja danych, to wyborem powinien być WiseWan 2000, ponieważ więcej sensu ma wykonywanie kompresji na szeregowych połączeniach WAN niż w wewnętrznej sieci kampusowej.

Produkt taki jak PacketShaper - zlokalizowany wewnątrz routera i dostarczający ruch do niego - nie kontroluje tego, czy dany ruch jest skierowany na zewnątrz przez połączenia WAN, czy też jest to ruch lokalny. Z tego powodu nie może podejmować sensownych decyzji o zastosowaniu kompresji.

Produkt taki jak PacketShaper może być użyteczny wtedy, gdy jest potrzebny rozdział pasma na różne typy ruchu wychodzącego, ponieważ może określić, jakiego typu ruchu wymagają poszczególni użytkownicy i na tej podstawie można rozdzielać pasmo dla tych aplikacji.

Buforowanie

Po wdrożeniu regulatorów pakietów, zapewniających lepsze zarządzanie pasmem, można wykonać krok następny: wdrożyć system buforujący, oszczędzający pasmo przez zaniechanie transmisji.

Buforowanie Weba przyspiesza dostarczanie zawartości stron webowych. Buforowanie wykorzystuje fakt, że grupa użytkowników może potrzebować tej samej informacji z Weba wielokrotnie. Ponieważ gros zawartości jest statyczna, niecelowe jest pobieranie za każdym razem świeżej kopii przez relatywnie powolne połączenia internetowe. Efektywniejsze jest zapamiętanie raz pobranej kopii danych webowych blisko żądającego ich użytkownika, zapewniające w ten sposób krótszy czas reakcji na ponowne żądanie i oszczędzające pasmo.

Użytkownicy wewnętrzni zlecający pobieranie danych webowych "przechodzą" najpierw przez bufor. Zlecenie takie jest ekspediowane przez Internet do serwera webowego jedynie wtedy, gdy bufor nie zawiera żądanej informacji. W takim scenariuszu lepszy czas reakcji uzyskuje się kosztem "świeżości" tej informacji.

Alternatywnym rozwiązaniem jest umieszczenie urządzenia buforującego bliżej serwera webowego, w formie procesora przyczółkowego (front end processor) rozładowującego zlecenia dla najczęściej pobieranych z serwera stron. Takie rozwiązanie jest nazywane czasami buforowaniem odwróconym (reverse caching). Ponieważ często żądane strony są buforowane, motor buforujący po prostu zawraca bezpośrednio taką stronę do urządzenia zlecającego, zamiast przekazywać zlecenia do serwera webowego. Przykładem takich rozwiązań są produkty firm CacheFlow i Cobalt Network. Różnice w implementacji tej techniki sprowadzają się zazwyczaj do sposobu przetwarzania zlecenia pobrania strony. I tak na przykład CacheOS firmy CacheFlow przysłania adres IP stacji klienckiej, żądającej danych z serwera webowego, i prezentuje serwerowi jedynie adres IP urządzenia buforującego. Z kolei CascheRaQ firmy Cobalt Network przechowuje adres IP klienta zlecającego i prezentuje go serwerowi webowemu w zleceniu „get”. W tym drugim rozwiązaniu może zachodzić niebezpieczeństwo nieumyślnego ujawnienia na zewnątrz adresu IP klienta wewnętrznego. Takie eksponowanie wewnętrznego adresu IP może narazić system na poważne zagrożenie.