Is there anyway to tell what user will receive data from inbound packet?

This is not achievable natively within the TCP/IP protocol, because... well, that's just not how the protocol works - it doesn't have a concept of users, and is designed to just transfer data between devices.

The way this is generally done (rate-limiting a specific remote user) is through the use of sessions (layer 5 in your OSI networking model, which is 1 or 2 layers higher than TCP/IP). You assign something unique to each user, like a cookie or a token, so that you can correlate individual sessions to specific users, which you can then pass to your rate-limiter (as opposed to just an IP address, which is the simple way of doing it).

Yes, you can use the Ident protocol to identify the user at the source.

Well, you used to be able to. Nowadays the only people who expose ident servers to the Internet at large are IRC users who want a funky nickname.

Oh, and people who've misconfigured their systems.

Traffic shaping for your users isn't a bad idea, but you're going about it in the wrong way - specifically, you're insisting on trying to shape inbound traffic. This quote comes from the Linux Advanced Routing and Traffic Control HOWTO

With queueing we determine the way in which data is SENT. It is important to realise that we can only shape data that we transmit.

With the way the Internet works, we have no direct control of what people send us. It's a bit like your (physical!) mailbox at home. There is no way you can influence the world to modify the amount of mail they send you, short of contacting everybody.

[...]

If you have a router and wish to prevent certain hosts within your network from downloading too fast, you need to do your shaping on the inner interface of your router, the one that sends data to your own computers.

As voretaq7 and MikeyB have said in their comments on Hopeless Noob's answer, you have decided to accomplish underlying task X by method Y, and you're asking us all about method Y. Sadly, method Y is the wrong way to accomplish task X. This is leading to unproductive answers and general frustration.

There are usually reasons why things are the way they are, and in free software, those methods are rarely related to marketing or other irrelevancies; they are often (though by no means always) related to facts and reality. So, sit down and read about the methods provided to achieve what you're trying to achieve, and then work out how to use those methods to solve your particular problem.

Edit: trickle isn't working with the network stack at all; it gets involved far earlier than that by intercepting calls to glibc's networking code for dynmically-linked binaries that use TCP as a transport mechanism.

That doesn't prove that traffic-shaping can be used on inbound traffic, it proves there are other approaches to limiting network throughput than working directly with the kernel's network stack. You could also do what you want with an authenticating proxy, eg squid which can do per-user bandwidth quotas.

Let me be clear: I'm not saying that what you want is impossible. I'm saying I don't believe you can or should do it with inbound traffic-shaping.

Both squid and trickle actually make voretaq7/MikeyB's point: that if you had asked how to achieve what you actually want done, you would have got much better answers.

If the iptables rules are applied on the host where the client is running, then you can make use of the owner module. This only works with outgoing packets, so you'd need to use CONNMARK target to store information from outgoing packets which you need when processing incoming packets.

That approach does not work, if the packets are traveling over a network link between the client and the firewall. Around 15 years ago, I heard about a research project trying to extent the IP packets on the LAN with information, which would allow the firewall to apply rules similar to the owner module. I don't think the implementation ever got used in any real production environment.

Sticking with already deployed protocols, the ident protocol the answer from @MikeyB may be the only option. Unfortunately having the firewall do extra communication in order to process a packet is not a good option. Having to buffer a packet such that the fate of the packet can depend on packets received at a later time, may require a fundamental design change in the packet filtering. Also you are going to have added latency due to needing a couple of roundtrips to communicate with the ident daemon. You also have to take care to avoid cyclic dependencies, because you are making packet forwarding (i.e. the IP layer) depend on the ident protocol, which is running on top of TCP.

The extra latency may be avoidable, if by the time the SYN packet from the client is forwarded, the ident communication is initiated. Then it it will likely have completed before the final ACK of the TCP handshake. However initiating ident communication that early will make the firewall very vulnerable to SYN-flooding from the LAN side. Initiating ident communication later will make the attack marginally harder while still having a chance of completing ident communication before the first data packet need to be forwarded. However you are putting the protection against a SYN-flood from your LAN in the hands of random servers on the Internet. A host on your LAN could easily collude with a host on the Internet to perform a flood, which is difficult to protect against. This may not be a new problem though, any stateful firewall could be vulnerable to such attacks.

It is important to keep in mind, that in every situation, the administrator of the host where the client is running decides, if user information will be available to you or not. So you have to be prepared to handle situations in which user information is not available to you.