* [LARTC] Re: per-session QoS
@ 2004-02-06 2:03 Nuutti Kotivuori
2004-02-06 3:27 ` Ben
2004-02-06 3:43 ` Nuutti Kotivuori
0 siblings, 2 replies; 3+ messages in thread
From: Nuutti Kotivuori @ 2004-02-06 2:03 UTC (permalink / raw)
To: lartc
Ben wrote:
> Hey guys, I'm looking for a way to limit ingress throughput for each
> tcp session to a destination port on my server. I've found lots of
> ways to limit total throughput to a given port on an ip-level, but
> that's not quite the same thing.
>
> I'm somewhat surprised this doesn't seem to be implemented
> already. Maybe it is and I'm not seeing it?
I have a need for a very similar thing. But in my case, I wish to
schedule tcp sessions to a different transfer class if they transfer
faster than a certain speed.
Doing this on the actual traffic control side of things seems tricky,
since none of them have any notion of connections or tcp
sessions. Doing this by the way of the 'connbytes' match, eg. by
storing the data in the connection tracking table, seems rather easily
doable.
What you would wish to do is have a simple per connection token
bucket, and just DROP every packet exceeding the rate in the
connection, am I right?
What I would wish is a bit more complex. I'd like to have per
connection token bucket, but have it such that when it runs out of
tokens, the rule stops matching, but every packet will still take
whatever tokens there are in the bucket. And the rule would start
matching again only after a certain amount of tokens has again been
amassed in the bucket. This is to prevent too rapid churn between
different transfer classes per connection.
And I haven't found anything which would do this for me anywhere.
So, I might code it myself if no other solution comes up.
-- Naked
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [LARTC] Re: per-session QoS
2004-02-06 2:03 [LARTC] Re: per-session QoS Nuutti Kotivuori
@ 2004-02-06 3:27 ` Ben
2004-02-06 3:43 ` Nuutti Kotivuori
1 sibling, 0 replies; 3+ messages in thread
From: Ben @ 2004-02-06 3:27 UTC (permalink / raw)
To: lartc
On Thu, 2004-02-05 at 18:03, Nuutti Kotivuori wrote:
> What you would wish to do is have a simple per connection token
> bucket, and just DROP every packet exceeding the rate in the
> connection, am I right?
I don't want to loose data, so dropping packets definately seems like
the wrong thing to do. Unless that's how ingress filters work? I haven't
used them before.
Fortunately I have access to the code of my server application, because
it sounds like the easiest thing is going to be to just put per-session
rate limiting into that.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [LARTC] Re: per-session QoS
2004-02-06 2:03 [LARTC] Re: per-session QoS Nuutti Kotivuori
2004-02-06 3:27 ` Ben
@ 2004-02-06 3:43 ` Nuutti Kotivuori
1 sibling, 0 replies; 3+ messages in thread
From: Nuutti Kotivuori @ 2004-02-06 3:43 UTC (permalink / raw)
To: lartc
Ben wrote:
> On Thu, 2004-02-05 at 18:03, Nuutti Kotivuori wrote:
>
>> What you would wish to do is have a simple per connection token
>> bucket, and just DROP every packet exceeding the rate in the
>> connection, am I right?
>
> I don't want to loose data, so dropping packets definately seems
> like the wrong thing to do. Unless that's how ingress filters work?
> I haven't used them before.
Dropping packets will not mean losing data - it just means that the
TCP connections have to resend the packets and in general means that
the connection will throttle itself to the configured rate.
But ingress filtering as it is now works exactly like that. The packet
that you are receiving has already reached your machine and you either
drop it or accept it. If you wish to do something further, you can
look into IMQ.
> Fortunately I have access to the code of my server application,
> because it sounds like the easiest thing is going to be to just put
> per-session rate limiting into that.
Right, well, it probably is the easiest solution - just note that you
will be working from behind your own receive buffers and tcp windows,
which means that the connection might initially accept (burst) more
data than you expect before the buffers fill.
-- Naked
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-02-06 3:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-06 2:03 [LARTC] Re: per-session QoS Nuutti Kotivuori
2004-02-06 3:27 ` Ben
2004-02-06 3:43 ` Nuutti Kotivuori
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.