Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Kea Kea
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 505
    • Issues 505
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 51
    • Merge requests 51
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • KeaKea
  • Issues
  • #42

Closed
Open
Created Aug 24, 2018 by Ghost User@ghost

Congestion handling

I propose two ways to control the receive queue to avoid big backlogs which can happen when servicing is too slow (and the fact clients retransmit of course does not help at all).

First is the POSIX setsockopt(SO_RCVBUF) which sets the maximum size in bytes of the socket receive queue. When the queue is full (i.e. an incoming packet is bigger than the maximum minus the current size) new packets are dropped instead added at the end of the queue. This allows to avoid big backlog but as it drops new packets it is not the best/only solution.

Second idea is to use ioctl(FIONREAD) which returns the current size in bytes of the receive queue (very efficient system call BTW). I propose to use it in two ways:

  • when it returns a large value (threshold to determine) packets should be simply popped and dropped.
  • after servicing a packet it is more efficient to look at if there is another one than to come back to select (a real performance pig). Of course only a limited (another parameter to determine) number of packets should be serviced because the select loop includes other services.

About the last part of the second idea I refer to the AFTR code where I implemented this. Note there is a big theoretical and practical background on the way to manage queue in high load / congestion situations, e.g RED (Random Early Detection). A good subject for a student...

The earlier issue that covered initial discussion and some experiments is #49 (closed). Adding the number for easier reference.

Edited Nov 07, 2018 by Tomek Mrugalski
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking