concatenate udp payloads of multiple packet

concatenate udp payloads of multiple packet

[Arif Hossain]

Hi all.

I have a netfilter_queue app which receives packets on a port range
and do modifications on them. Now  i need to introduce to new features
with this basic app.

First the traffic is quiet high. I have seen the --queue-balance
option. If i want to use it how should i approach? i mean should i
manage every queue from separate threads or
separate process to manage individual queues?  I'm not sure how can i
use fork() to manage every queue separately.

Secondly How packets are distributed among different queues? Based on
what property a  packet is distributed? Any relationship i need to
know about
this distribution?

Thirdly I need to concatenate udp payloads of several packet to
improve bandwidth usage. how should i approach this? The confusion is
when i stop finish processing
of one packet i call nfq_set_verdict() in nfq_callback().  My
confusion  is when  a packet popped from the NFQUEUE? when
nfq_set_verdict() returns or when nfq_callback()
returns?

I mean if i push the incoming packets in user managed queues for
concatenation of udp payload(by this i will also drop individual
packets), then return from the nfq_callback().
After processing in user managed queues(concatenation is done) then i
will issue nfq_set_verdict(). Would that work?

Thanks in advance.

--
-aft
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: concatenate udp payloads of multiple packet

[Jeff Haran]

> -----Original Message-----
> From: netfilter-devel-owner@vger.kernel.org [mailto:netfilter-devel-
> owner@vger.kernel.org] On Behalf Of Arif Hossain
> Sent: Thursday, April 19, 2012 7:32 AM
> To: netfilter@vger.kernel.org; netfilter-devel@vger.kernel.org
> Subject: concatenate udp payloads of multiple packet
> 
> Hi all.
> 
> I have a netfilter_queue app which receives packets on a port range
> and do modifications on them. Now  i need to introduce to new features
> with this basic app.
> 
> First the traffic is quiet high. I have seen the --queue-balance
> option. If i want to use it how should i approach? i mean should i
> manage every queue from separate threads or
> separate process to manage individual queues?  I'm not sure how can i
> use fork() to manage every queue separately.
> 
> Secondly How packets are distributed among different queues? Based on
> what property a  packet is distributed? Any relationship i need to
> know about
> this distribution?
> 
> Thirdly I need to concatenate udp payloads of several packet to
> improve bandwidth usage. how should i approach this? The confusion is
> when i stop finish processing
> of one packet i call nfq_set_verdict() in nfq_callback().  My
> confusion  is when  a packet popped from the NFQUEUE? when
> nfq_set_verdict() returns or when nfq_callback()
> returns?
> 
> I mean if i push the incoming packets in user managed queues for
> concatenation of udp payload(by this i will also drop individual
> packets), then return from the nfq_callback().
> After processing in user managed queues(concatenation is done) then i
> will issue nfq_set_verdict(). Would that work?
> 
> Thanks in advance.
> 
> --
> -aft

I'm not an expert in this interface, but what I've observed is when user space reads a packet off of a socket to an NFQUEUE, a subsequent read on that socket will block if the first packet is not returned via nfq_set_verdict(), even if further packets have been queued from the kernel. So I don't think you can expect to read a bunch of packets, concatenate them and then return verdicts on them. You'd never see packets past the first one. At least that's what I have observed. I haven't dug into the kernel code to see if that is expected behavior.

I had written an application which poll()'ed on two fds; one a socket to an NFQUEUE and another from signalfd() to SIGUSR1. The "handler" code for the SIGUSR1 signal fd just printf()'ed some statistics maintained by the application. Funny thing was, if ever my application failed to call nfq_set_verdict() for a packet read off of the socket, then poll() wouldn't return even when I sent the application a SIGUSR1 via kill. Not sure what was going on there.

Good luck,

Jeff Haran



--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: concatenate udp payloads of multiple packet

[Arif Hossain]

On Fri, Apr 20, 2012 at 11:17 PM, Jeff Haran <jharan@bytemobile.com> wrote:
> Nothing prevents you from having multiple NFQUEUEs using the queue-balance option to the NFQUEUE target. From the iptables man page:
>
> "NFQUEUE
>
> This target is an extension of the QUEUE target. As opposed to QUEUE, it allows you to put a packet into any specific queue, identified by its 16-bit queue number. It can only be used with Kernel versions 2.6.14 or later, since it requires the nfnetlink_queue kernel support. The queue-balance option was added in Linux 2.6.31.
> --queue-num value
> This specifies the QUEUE number to use. Valid queue numbers are 0 to 65535. The default value is 0.
> --queue-balance value:value
> This specifies a range of queues to use. Packets are then balanced across the given queues. This is useful for multicore systems: start multiple instances of the userspace program on queues x, x+1, .. x+n and use "--queue-balance x:x+n". Packets belonging to the same connection are put into the same nfqueue."
>
> However, on each of those queues, when you read a packet from the socket to the queue you have to return a verdict on that packet before you get any more packets off that socket. At least that's what I've observed.
>
> Jeff Haran
>

I do use the queue-balance option to use multiple cores of the
machines by means of separate application.

But for my purpose, concatenation of udp payload this does not help.
What i've come to understand that there is no straight forward way to
achieve this.

But if i do this in following way would that work:

I will save the udp payload in a user   managed queue and set the
verdict as NF_DROP to every packet. after creating the concatenated
packet, i will forward the message to the udp daemon.

What are difficulties i may face if i chose to do it in this way?



-- 
-aft

RE: concatenate udp payloads of multiple packet

[Jan Engelhardt]

On Thursday 2012-04-19 19:58, Jeff Haran wrote:
>
>I'm not an expert in this interface, but what I've observed is when user space
>reads a packet off of a socket to an NFQUEUE, a subsequent read on that socket
>will block if the first packet is not returned via nfq_set_verdict(), even if
>further packets have been queued from the kernel.

So simply set the verdict to NF_DROP for every input frame and send out
combined frames that are not linked to any prior packet.
So far the theory.

Re: concatenate udp payloads of multiple packet

[Rick Jones]

On 04/19/2012 07:32 AM, Arif Hossain wrote:
> Thirdly I need to concatenate udp payloads of several packet to
> improve bandwidth usage. how should i approach this?

It isn't clear you can.  An application using UDP is expecting message 
boundaries to be preserved.  That is a fundamental part of the semantics 
of UDP.  So if an application has sent three, 128 byte messages via UDP, 
the receiving side is expecting to receive three, 128 byte messages, not 
one 384 byte message.  If the receiver can indeed deal with just one, 
384 byte message, that is what the sending side should have sent in the 
first place.

rick jones

Re: concatenate udp payloads of multiple packet

[Arif Hossain]

> It isn't clear you can.  An application using UDP is expecting message
> boundaries to be preserved.  That is a fundamental part of the semantics of
> UDP.  So if an application has sent three, 128 byte messages via UDP, the
> receiving side is expecting to receive three, 128 byte messages, not one 384
> byte message.  If the receiver can indeed deal with just one, 384 byte
> message, that is what the sending side should have sent in the first place.
>

Ok i'm explaining it a bit more so no confusion about what i'm trying
to achieve.

In our application, we are send
RTP(http://en.wikipedia.org/wiki/Real-time_Transport_Protocol)
packets. These RTP packets have encoded voice data as their payload.
When a voice communication
occurs its quiet bandwidth consuming. Thousands of udp packets are
transmitted in a matter of seconds.
So when a client is in low bandwidth area, its more logical to send
large udp packts with multiple rtp packets
concatenated.

Take for instance G729 codec has a 10ms frame. which is encoded as 10
bytes of voice data. every rtp packets has
12 bytes of header. its totally wasteful of bandwidth that to send
only 10 bytes of voice data as a payload of 12 bytes of header.
If 5 RTP frames are concatenated then we are transmitting 50 bytes
with a single 12 byte header. then payload to header ratio
is 50/12 which far less than 10/12. The more bigger packet we send the
more this ratio increase and so our bandwidth
consumption reduced. But there is also a trade off. the more frames we
send in packet the quality of voice decreases slightly.

After some testing we have come to conclusion that sending 10 packets
in a single udp datagram is a optimum choice.

We use our existing netfilter_queue app to encryption/obfuscation of
voice data to escape certain firewall and telecom operators
malpractices. For improving our service we have decided that we will
increase our payload size.

Problem is different SIP servers vary in their capability of repack
RTP packets.  some can do a lot but other's do not. we do not want to
select a
telephony  server based on this property because lot of other
variables are involved in the selection process. And for different
services we use several
Telephony platform.

So we want our application to be capable of repack rtp packets so that
we can use whatever telephony platforms we want without thinking about
this.
This way our service implementation will be more robust and will not
create unnecessary dependencies.

Thank you for your reply



-- 
-aft
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html