Hacker News new | past | comments | ask | show | jobs | submit login

They drop your packets, both for ingoing and outgoing overflow.



But how is that different from the proposed method of rate limited which causes "excessive retransmits and bandwidth waste"?

Not being pedantic, genuinely trying to understand how this stuff works.


Middle ground between dropping [1] and buffering is Active Queue Management as wtallis pointed out above. State of the art AQM on Linux nowadays is CoDel [2].

Big network gear vendors that ship to ISPs have adopted early forms of AQM (both RED [3] and proprietary algorithms) quite a while ago - they had to:

(a) backbone routers have much smaller buffer-to-bandwidth ratio (compared to a PC or even home router), so endless buffering is not an option;

(b) buffer tail drops (i.e. what drop keyword does when added to tc filters/disciplines) interact really poorly with TCP bandwidth control algorithms, and rather badly with RTP streams, too (so drop is not an option either - it ruins user's connections; and

(c) ISPs and carriers would typically run links (on average) much closer to saturation than your typical home router, so situation where router has to make buffer/drop decision is much, much more frequent.

[1] My point above was that you don't really want to drop packets on the receiver side, after that packet already traversed expensive part of the network.

[2] https://en.wikipedia.org/wiki/CoDel

[3] https://en.wikipedia.org/wiki/Random_early_detection




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: