Řešil jsme to v případě přechodu z jednoho o hodně rychlejšího rozhraní, do pomalejšího. Typicky Gbit CCR do radia (i přes switch) do nějakého standardního MT, nebo i do klasického PDH, který díky tomu, že to je není simplex, tak to tam umí narvat pěkně po sobě. U klasickýho simplexu, ale přepínáním dochází k plnění bufferů na MAC vrstvě, ale nezabezpečuje to mezipaketové mezery na ETH. Po aktivaci Flowcontrolu problémy zmizí, protože vstupní ETH si řekne jenom o takové množství dat a mezipaketových mezer, které dovede MAC vrstva simplexniho radia odbavit. Velké buffery jsou fajn, ale jsou doménou právě dražších routovacích platforem. Pokud to není ošetřené, tak se není čemu divit. Pak je jasné, že stavová logika pakety zahazuje, protože přetečou vstupní buffery ETH, který to nemá kam dál podat a holt to zahodí. K tomu ale právě slouží flow control který domluví s adapterem protější strany dávkování dat pouze s takovou mezipaketou mezerou, která zajistí jejich vypravení dalším aktivním prvkem, protože ten si o data "žádá" rychlostí a dávkováním, aby to vyhovělo MAC radia.
Přetečený buffer na ETH i u TCP znamená zahozený paket a jeho znovu vyžádání na základě absence ACK, to trvá .. - to bere čas a ten znamená malou propustnost, nehledě na špatné pořadí paketů. Když se to zřetězí, nené se čemu divit.
