1

I need to estimate the bandwidth for a measurement application to be written that uses UDP. I have a good sense of the numbers but am not sure how to put them together. I checked a few throughput calculators such as this, but most are for TCP so not completely applicable.

  • UDP request: <100 bytes (the complete packet, as it'd be seen in tcpdump)
  • UDP response: <200 bytes
  • latency between request-response: 80ms on average
  • there will be N (say, 80) parallel threads going on continuously. There is some time spent with processing the responses, but for the purpose of this question, let's ignore that and assume the ideal case in which a request is immediate after the response.
wishihadabettername
  • 111
  • 1
  • 3
  • I think you've got it. You could either write a scripts to model it and measure the bandwidth crossing your interface. Another thing to try is get a copy of LANforge and emulate the traffic with as many vlans as you'd like. – memnoch_proxy May 24 '14 at 14:20
  • Your actual bandwidth will fluctuate a bit of course. Are you collecting this data in a predictable network environment? Do you have bandwidth limits for your equipment? For instance, you could be monitoring raspberry-pi data on a 100Mbps switch. If your traffic has to cross routers, you also want to include jitter for the router. – memnoch_proxy May 24 '14 at 14:40
  • @memnoch_proxy The environment is not completely predictable; but at this stage they need to know the bandwidth that is consumed by the system. The collection rate will be adjusted based on that, there is some flexibility. – wishihadabettername May 24 '14 at 15:47

1 Answers1

1

The question you should be asking is, how many requests do you need to process per second. That number is missing from your question, and as such the original question cannot be answered appropriately.

There is however a few numbers in your question that I can give an answer to.

First of all you mention a request size of 100 bytes and a reply size of 200 bytes. A UDP service where replies are larger than requests can potentially be abused for reflection attacks. This is something that must be taken into account when designing UDP based protocols.

Another important consideration is the possibility that a stray packet is mistakenly interpreted as a request.

You mention the possibility of using 80 threads. TCP based services mainly use large number of threads because they are often designed such that every connection requires a thread, and that thread may spend lots of time simply waiting for the client.

Such waiting periods won't happen in a UDP based service. This means you should only be using 80 threads, if you expect all 80 threads to be doing actual processing in parallel. It requires a quite powerful machine to have 80 threads doing actual processing in parallel.

If you are doing heavy processing without first doing your own verification of the client IP address, you'll be an easy target for DoS attacks.

If you are implementing a UDP based protocol and you are using multiple threads, you are probably doing it wrong.

kasperd
  • 30,455
  • 17
  • 76
  • 124
  • Well, not always. A UDP-based file service (i.e. NFS) could use threads effectively, but otherwise everything in that answer is spot on. – Fred the Magic Wonder Dog May 24 '14 at 14:30
  • @kasperd Thanks for the comments. In this case, there are no hard requirements for the requests/sec (it's a data collection app) but the impact on the network traffic matters. The app will not run on the open internet and therefore is not subject to reflection attacks (that's a good point, though). – wishihadabettername May 24 '14 at 14:32
  • The "threads" are referenced there for bandwidth calculation purposes (yes, there is some processing done afterwards and it's easier to do it in a thread with its own queue with a timeout per request rather than a loop). The topology may use a few machines instead of a single one to achieve the (loose) number of 80 parallel requests. – wishihadabettername May 24 '14 at 14:36
  • @FredtheMagicWonderDog NFS does some validation of the clients first which makes a major difference. I can't claim to know NFS in enough detail to say if that validation is done correctly, neither can I say if NFS deals with congestion as gracefully as TCP does. – kasperd May 24 '14 at 15:10
  • @wishihadabettername A person whose name I shall not mention here wrote a UDP service several years ago which he assumed was never going to be running on a public IP address. A few months later he had to be woken up in the middle of the night, because his code was flooding an innocent network somewhere on the Internet with 90 Mbit/s of UDP packets, which was a lot at that time. – kasperd May 24 '14 at 15:13
  • @wishihadabettername Notice that even if the service really isn't on the Internet, reflection can happen in two stages. First a packet with spoofed source IP is reflected off a machine, which has access to both the Internet and your service. The service on that other machine may be well designed and respond to that packet with a reply which is slightly smaller than the spoofed packet. That reply now goes to your service, which may respond with a larger answer. – kasperd May 24 '14 at 15:19
  • #kasperd All good points. In this case UDP is imposed by the existing system (with sensors that only talk UDP). – wishihadabettername May 24 '14 at 15:49
  • @wishihadabettername Now I realize that it is not entirely clear from your question if you are writing the client code or the server code, or if the protocol might be using a different model, where there is no such thing as client and server. – kasperd May 24 '14 at 16:15
  • @kasperd The client (that connects to those sensors, requesting something and receiving the answer). The protocol is set by them. The devices only know to respond to queries. – wishihadabettername May 24 '14 at 17:08