prio + policing filter on ingress?

prio + policing filter on ingress?

[Lloyd Standish]

Hello All,

I would like to police traffic (bandwidth-limit with drop) on ingress of an outward-facing interface, but I would also like to make sure that inbound traffic destined for a certain IP is dropped *before* traffic to the other IPs.  I think I can do this by combining a prio qdisc with a policing filter via ifb.  I have never seen an example of this; I don't know whether or not it's possible.

All I have so far is the ingress prio qdisc.  I don't know how to add the policing filter to it.  (I wonder if I would have to add a policing filter to each of the prio's bands.  In that case I could not limit the total bandwidth of the interface.)

eth0 is the inbound interface.

tc qdisc add dev eth0 ingress
tc qdisc add dev ifb0 root handle 1: prio default 1
tc qdisc add dev ifb0 parent 1:1 sfq perturb 10 limit 3000
tc qdisc add dev ifb0 parent 1:2 sfq perturb 10
tc qdisc add dev ifb0 parent 1:3 sfq perturb 10

# filters to put packets in different prio bands, only 2 are shown.

# DNS
tc filter add dev ifb0 protocol ip parent 1: prio 1 u32 match ip sport 53 0xffff flowid 1:1
# http
tc filter add dev ifb0 protocol ip parent 1: prio 3 u32 match ip sport 80 0xffff flowid 1:2

# put traffic to LAN IP 192.168.0.5 in the lowest priority prio band
tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip dst 192.168.0.5 flowid 1:3

# all unfiltered traffic goes to prio band 2
tc filter add dev ifb0 parent 1: protocol ip prio 4 u32 match ip dst 0.0.0.0/0 flowid 1:2

#
## how to add a policing filter to limit the bandwidth of the entire interface, and drop extra bandwidth from prio band 3 first?
#
tc filter add dev eth0 parent ffff: protocol ip prio 1 u32 match ip dst 0.0.0.0/0 flowid :1 \
   action mirred egress redirect dev ifb0

Thanks in advance for any help.
-- 
Lloyd

Re: prio + policing filter on ingress?

[Andrew Beverley]

On Mon, 2011-12-12 at 09:27 -0600, Lloyd Standish wrote:
> Hello All,
> 
> I would like to police traffic (bandwidth-limit with drop) on ingress
>  of an outward-facing interface, but I would also like to make sure
>  that inbound traffic destined for a certain IP is dropped *before*
>  traffic to the other IPs.  I think I can do this by combining a prio
>  qdisc with a policing filter via ifb.  I have never seen an example of
>  this; I don't know whether or not it's possible.
> 
> All I have so far is the ingress prio qdisc.  I don't know how to add
>  the policing filter to it.  (I wonder if I would have to add a
>  policing filter to each of the prio's bands.  In that case I could not
>  limit the total bandwidth of the interface.)
> 
> eth0 is the inbound interface.
> 
> tc qdisc add dev eth0 ingress
> tc qdisc add dev ifb0 root handle 1: prio default 1
> tc qdisc add dev ifb0 parent 1:1 sfq perturb 10 limit 3000
> tc qdisc add dev ifb0 parent 1:2 sfq perturb 10
> tc qdisc add dev ifb0 parent 1:3 sfq perturb 10
> 
> # filters to put packets in different prio bands, only 2 are shown.
> 
> # DNS
> tc filter add dev ifb0 protocol ip parent 1: prio 1 u32 match ip sport 53 0xffff flowid 1:1
> # http
> tc filter add dev ifb0 protocol ip parent 1: prio 3 u32 match ip sport 80 0xffff flowid 1:2
> 
> # put traffic to LAN IP 192.168.0.5 in the lowest priority prio band
> tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip dst 192.168.0.5 flowid 1:3
> 
> # all unfiltered traffic goes to prio band 2
> tc filter add dev ifb0 parent 1: protocol ip prio 4 u32 match ip dst 0.0.0.0/0 flowid 1:2
> 
> #
> ## how to add a policing filter to limit the bandwidth of the entire interface, and drop extra bandwidth from prio band 3 first?
> #
> tc filter add dev eth0 parent ffff: protocol ip prio 1 u32 match ip dst 0.0.0.0/0 flowid :1 \
>    action mirred egress redirect dev ifb0

Interesting case, which I think you've made a good start at. I don't
have the textbook answer for you, but a couple of thoughts (I don't know
whether these will necessarily work):

- Could you do the policing by attaching an ingress qdisc to eth0 (in
addition to the above rules)?

- Could you set up another IFB device (that receives the same traffic)
with a policer attached to it?

- Could you do some sort of parent/child set up, such as a PRIO as the
child of a HTB, so that the parent does the policing and the PRIO does
the priority (although having just read the Traffic Control HOWTO you
may not be able to do this because you cannot have differing types of
qdiscs within each other).

Andy

Re: prio + policing filter on ingress?

[Lloyd Standish]

On Tue, 13 Dec 2011 12:25:24 -0600, Andrew Beverley <andy@andybev.com> wrote:

> Interesting case, which I think you've made a good start at. I don't
> have the textbook answer for you, but a couple of thoughts (I don't know
> whether these will necessarily work):
> - Could you do the policing by attaching an ingress qdisc to eth0 (in
> addition to the above rules)?

That's what I did at first (still untested).  I have a policing qdisc on ingress of each of the outward-facing interfaces, and I put a prio qdisc with filters as in my example on egress of the inward-facing (LAN) interface.  But I have my doubts this will work, since the policing qdiscs should pretty much eliminate any inbound queue in the router, right?

I should explain the goal here.  There are 5 outward-facing interfaces, and the router load-balances over them using ip and "nexthop via".  Each interface is currently only 5 Mgit, policed to 4 Mbit with ingress qdiscs, to keep the upstream provider from queuing, to improve latency.  This is for a small ISP (about 70 customers) belonging to a friend.  Internet is distributed via a wireless LAN to customers. The customers' radios do the bandwidth-limiting.  A typical download speed is 500Kbit.

Now, my friend wants to be able to make personal use of the UNUSED bandwidth without infringing on his customers' paid bandwidth.  So I got the idea of putting all traffic to his IP (192.168.0.5 in my example) into band 3 of a prio qdisc.

It seems to me that for this to work, a way has to be found for the policer to drop over-bandwidth packets bound for my friend's IP before it drops customers packets.  Would that enable customers to get their full download bandwidth, while giving access to EXTRA bandwidth to my friend?  I'm not even sure this would work in theory.

> - Could you set up another IFB device (that receives the same traffic)
> with a policer attached to it?

I'm not sure what you mean.  Can 2 ifb devices on the same interface receive the same traffic?
> - Could you do some sort of parent/child set up, such as a PRIO as the
> child of a HTB, so that the parent does the policing and the PRIO does
> the priority (although having just read the Traffic Control HOWTO you
> may not be able to do this because you cannot have differing types of
> qdiscs within each other).

Hmmm, I know it is possible to have HTB as root qdisc with PRIO as child, but I don't know how to combine a policing filter with PRIO.

I think the only way to do this may be to do bandwidth-limiting in the router (rather than in the radio) with HTB classes for each customer, with CEIL = total bandwidth for my ISP's personal IP.  Policing would remain on ingress of each outward-facing interface.

-- 
Lloyd

Re: prio + policing filter on ingress?

[Andrew Beverley]

On Tue, 2011-12-13 at 14:19 -0600, Lloyd Standish wrote:
> On Tue, 13 Dec 2011 12:25:24 -0600, Andrew Beverley <andy@andybev.com> wrote:
> 
> > Interesting case, which I think you've made a good start at. I don't
> > have the textbook answer for you, but a couple of thoughts (I don't know
> > whether these will necessarily work):
> > - Could you do the policing by attaching an ingress qdisc to eth0 (in
> > addition to the above rules)?
> 
> That's what I did at first (still untested).  I have a policing qdisc
>  on ingress of each of the outward-facing interfaces, and I put a prio
>  qdisc with filters as in my example on egress of the inward-facing
>  (LAN) interface.  But I have my doubts this will work, since the
>  policing qdiscs should pretty much eliminate any inbound queue in the
>  router, right?

Yeah, good point, I hadn't thought of that.

> 
> I should explain the goal here.  There are 5 outward-facing interfaces,
>  and the router load-balances over them using ip and "nexthop via". 

Ah, I remember.

>  Each interface is currently only 5 Mgit, policed to 4 Mbit with
>  ingress qdiscs, to keep the upstream provider from queuing, to improve
>  latency.  This is for a small ISP (about 70 customers) belonging to a
>  friend.  Internet is distributed via a wireless LAN to customers. The
>  customers' radios do the bandwidth-limiting.  A typical download speed
>  is 500Kbit.
> 
> Now, my friend wants to be able to make personal use of the UNUSED
>  bandwidth without infringing on his customers' paid bandwidth.  So I
>  got the idea of putting all traffic to his IP (192.168.0.5 in my
>  example) into band 3 of a prio qdisc.

For you to do *exactly* what you describe, I think you'd have to use the
prio qdisc. And as you have found, it's quite limited. You could attach
a TBF qdisc to each leaf class to rate limit, but as you have already
alluded, this would not give an overall rate limit.

> 
> It seems to me that for this to work, a way has to be found for the
>  policer to drop over-bandwidth packets bound for my friend's IP before
>  it drops customers packets.  Would that enable customers to get their
>  full download bandwidth, while giving access to EXTRA bandwidth to my
>  friend?  I'm not even sure this would work in theory.

I think the only way you could do this is by using a single classful
qdisc for everything. You could try HTB with a suitable prio parameter
for your friend's class. Although it won't starve the class completely,
in my experience it will give it very little bandwidth if higher
priority classes have packets queued.

> 
> > - Could you set up another IFB device (that receives the same traffic)
> > with a policer attached to it?
> 
> I'm not sure what you mean.  Can 2 ifb devices on the same interface
>  receive the same traffic?

I did mean that. I don't know if it's even possible, but it probably
wouldn't work anyway for your reasons outlined above.

> I think the only way to do this may be to do bandwidth-limiting in the
>  router (rather than in the radio) with HTB classes for each customer,
>  with CEIL = total bandwidth for my ISP's personal IP.  Policing would
>  remain on ingress of each outward-facing interface.

See above. I reckon that's your only option. You could also check out
HFSC, but that's even more complicated...

Andy

Re: prio + policing filter on ingress?

[John A. Sullivan III]

On Tue, 2011-12-13 at 21:51 +0000, Andrew Beverley wrote:
> On Tue, 2011-12-13 at 14:19 -0600, Lloyd Standish wrote:
> > On Tue, 13 Dec 2011 12:25:24 -0600, Andrew Beverley <andy@andybev.com> wrote:
> > 
> > > Interesting case, which I think you've made a good start at. I don't
> > > have the textbook answer for you, but a couple of thoughts (I don't know
> > > whether these will necessarily work):
> > > - Could you do the policing by attaching an ingress qdisc to eth0 (in
> > > addition to the above rules)?
> > 
> > That's what I did at first (still untested).  I have a policing qdisc
> >  on ingress of each of the outward-facing interfaces, and I put a prio
> >  qdisc with filters as in my example on egress of the inward-facing
> >  (LAN) interface.  But I have my doubts this will work, since the
> >  policing qdiscs should pretty much eliminate any inbound queue in the
> >  router, right?
> 
> Yeah, good point, I hadn't thought of that.
> 
> > 
> > I should explain the goal here.  There are 5 outward-facing interfaces,
> >  and the router load-balances over them using ip and "nexthop via". 
> 
> Ah, I remember.
> 
> >  Each interface is currently only 5 Mgit, policed to 4 Mbit with
> >  ingress qdiscs, to keep the upstream provider from queuing, to improve
> >  latency.  This is for a small ISP (about 70 customers) belonging to a
> >  friend.  Internet is distributed via a wireless LAN to customers. The
> >  customers' radios do the bandwidth-limiting.  A typical download speed
> >  is 500Kbit.
> > 
> > Now, my friend wants to be able to make personal use of the UNUSED
> >  bandwidth without infringing on his customers' paid bandwidth.  So I
> >  got the idea of putting all traffic to his IP (192.168.0.5 in my
> >  example) into band 3 of a prio qdisc.
> 
> For you to do *exactly* what you describe, I think you'd have to use the
> prio qdisc. And as you have found, it's quite limited. You could attach
> a TBF qdisc to each leaf class to rate limit, but as you have already
> alluded, this would not give an overall rate limit.
> 
> > 
> > It seems to me that for this to work, a way has to be found for the
> >  policer to drop over-bandwidth packets bound for my friend's IP before
> >  it drops customers packets.  Would that enable customers to get their
> >  full download bandwidth, while giving access to EXTRA bandwidth to my
> >  friend?  I'm not even sure this would work in theory.
> 
> I think the only way you could do this is by using a single classful
> qdisc for everything. You could try HTB with a suitable prio parameter
> for your friend's class. Although it won't starve the class completely,
> in my experience it will give it very little bandwidth if higher
> priority classes have packets queued.
> 
> > 
> > > - Could you set up another IFB device (that receives the same traffic)
> > > with a policer attached to it?
> > 
> > I'm not sure what you mean.  Can 2 ifb devices on the same interface
> >  receive the same traffic?
> 
> I did mean that. I don't know if it's even possible, but it probably
> wouldn't work anyway for your reasons outlined above.
> 
> > I think the only way to do this may be to do bandwidth-limiting in the
> >  router (rather than in the radio) with HTB classes for each customer,
> >  with CEIL = total bandwidth for my ISP's personal IP.  Policing would
> >  remain on ingress of each outward-facing interface.
> 
> See above. I reckon that's your only option. You could also check out
> HFSC, but that's even more complicated...
<snip>
HFSC might not be a bad idea for you.  I'm still trying to get my head
around it but, one of the neat features is that the guaranteed bandwidth
rate can be separate from the rate at which excess available bandwidth
is shared. Thus, you could guarantee your friend only a minimal
bandwidth, guarantee the customers their allocated bandwidth but then
tell the system to give a much larger slice of the available excess
bandwidth to your friend than to the customers.  This way, he would get
as much as possible without compromising guarantees and, when he is not
using it, it is still shared among the other customers.  I'm still very
new at this so take all that with a big grain of salt! - John

Re: prio + policing filter on ingress?

[Andrew Beverley]

On Tue, 2011-12-13 at 17:53 -0500, John A. Sullivan III wrote:
> > > Now, my friend wants to be able to make personal use of the UNUSED
> > >  bandwidth without infringing on his customers' paid bandwidth.  So I
> > >  got the idea of putting all traffic to his IP (192.168.0.5 in my
> > >  example) into band 3 of a prio qdisc.
> > 
> > For you to do *exactly* what you describe, I think you'd have to use the
> > prio qdisc. And as you have found, it's quite limited. You could attach
> > a TBF qdisc to each leaf class to rate limit, but as you have already
> > alluded, this would not give an overall rate limit.

Well according to a question just posted to the (new) LARTC mailing
list, you can use HTB with a prio attached to one of the leafs. You
could try that. I.e. have a single HTB leaf, with a prio below it. The
HTB leaf will throttle your traffic, but I guess that the prio will
allow any demand on that throttled link to be prioritised, which will
then draw on the class above it as appropriate. Something like:

tc qdisc add dev ifb0 root handle 1 htb default 5000 r2q 6
tc class add dev ifb0 parent 1: classid 1:3 htb rate 100Mbit
tc qdisc add dev ifb0 parent 1:3 handle 5000 prio

> <snip>
> HFSC might not be a bad idea for you.  I'm still trying to get my head
> around it

Ah yes, I've noticed the questions on the netdev list. Thanks for that -
I just need to spend some time reading through the details now!

Andy

Re: prio + policing filter on ingress?

[Andy Furniss]

Andrew Beverley wrote:

>
> Well according to a question just posted to the (new) LARTC mailing
> list,

Interesting - where's the new list please?


>> HFSC might not be a bad idea for you.  I'm still trying to get my head
>> around it
>
> Ah yes, I've noticed the questions on the netdev list. Thanks for that -
> I just need to spend some time reading through the details now!

That's a lot to digest.

One thing that I recall from when hfsc first came out is that when 
testing it wouldn't limit bulk if the class wasn't backlogged.

For most people if you have enough bandwidth I doubt this is an issue, 
but at the time I was limiting for a 256kit dsl line with five users.

The hfsc paper says (IIRC) that the system will be backlogged until the 
last bit is transmitted - this would have made it really useful for me, 
but the Linux implementation didn't (doesn't?) seem to behave like this, 
so with five empty bulk classes firing five packets at them all would 
instantly dequeue borking my latency 5x more that I could achieve with 
htb classes with low burst set.

Of course htb isn't perfect and will sometime dequeue more than one at a 
time when multiple classes backlogged (hfsc probably wins in this case) 
it's just that one test put me off hfsc. Now I have more bandwidth this 
new documentation could be very useful - thanks for taking the time and 
effort.

I assume it's still "mean" by dropping unclassified traffic if you don't 
set a default class - that used to catch people out as htb was the 
opposite so at least you didn't loose your arp while playing around.

Re: prio + policing filter on ingress?

[John A. Sullivan III]

Hi, Andy.  I'll respond in line - John

On Thu, 2011-12-15 at 20:48 +0000, Andy Furniss wrote:
> Andrew Beverley wrote:
> 
> >
> > Well according to a question just posted to the (new) LARTC mailing
> > list,
> 
> Interesting - where's the new list please?
> 
> 
> >> HFSC might not be a bad idea for you.  I'm still trying to get my head
> >> around it
> >
> > Ah yes, I've noticed the questions on the netdev list. Thanks for that -
> > I just need to spend some time reading through the details now!
> 
> That's a lot to digest.
> 
> One thing that I recall from when hfsc first came out is that when 
> testing it wouldn't limit bulk if the class wasn't backlogged.
> 
> For most people if you have enough bandwidth I doubt this is an issue, 
> but at the time I was limiting for a 256kit dsl line with five users.
I haven't played around with it enough in the lab yet so I'm going
strictly on the theory.  I believe the class should backlog as soon as
there is a packet in queue.  An environment where bandwidth is so
constrained sounds like an ideal place to have separate rt and ls
curves.

The rt curve would allocate and guarantee a small amount of bandwidth to
each queue. If some of those classes have time sensitive traffic, you
could define a dilinear rt curve which would help jump those packets in
front of the others.  Then, with the ls curves, you could allocate spare
bandwidth.

> 
> The hfsc paper says (IIRC) that the system will be backlogged until the 
> last bit is transmitted - this would have made it really useful for me, 
> but the Linux implementation didn't (doesn't?) seem to behave like this, 
> so with five empty bulk classes firing five packets at them all would 
> instantly dequeue borking my latency 5x more that I could achieve with 
> htb classes with low burst set.
I think only one queue should dequeue and it will be chosen to ensure
that all rt guarantees are met.  Of course, with five full queues firing
full sized packets at 256kbit one can expect almost 250ms latency and
can only guarantee 50 kbits.  I suppose, if there was a latency
sensitive class, you could set all the rt m2 curves to something like
20kbit and set the time sensitive curve to something like umax 1514b
dmax 120ms which should ensure no more than 120ms latency for those
packets yet keep everything from starving.  If using something like VoIP
with smaller, 220b packets, you could do something like umax 220b dmax
20ms  The ls curves could then divvy up the bandwidth in the proportion
you want between the five streams.
> 
> Of course htb isn't perfect and will sometime dequeue more than one at a 
> time when multiple classes backlogged (hfsc probably wins in this case) 
> it's just that one test put me off hfsc. Now I have more bandwidth this 
> new documentation could be very useful - thanks for taking the time and 
> effort.
> 
> I assume it's still "mean" by dropping unclassified traffic if you don't 
> set a default class - that used to catch people out as htb was the 
> opposite so at least you didn't loose your arp while playing around.
I believe so.  Good luck - John

Re: prio + policing filter on ingress?

[Andy Furniss]

John A. Sullivan III wrote:

>> One thing that I recall from when hfsc first came out is that when
>> testing it wouldn't limit bulk if the class wasn't backlogged.
>>
>> For most people if you have enough bandwidth I doubt this is an issue,
>> but at the time I was limiting for a 256kit dsl line with five users.
> I haven't played around with it enough in the lab yet so I'm going
> strictly on the theory.  I believe the class should backlog as soon as
> there is a packet in queue.  An environment where bandwidth is so
> constrained sounds like an ideal place to have separate rt and ls
> curves.

Yea, I believe I did - but then it was a longtime ago. I think the issue 
was that an empty the class would dequeue instantly but the transmission 
time of that now gone packet didn't seem to affect other empty classes 
also receiving a packet. It would probably have only affected further 
packets to the same class.

I did raise it at the time and IIRC the author said that he would have 
to make hfsc even more non work conserving to deal with this case.

My test was a bit contrived I guess.

> The rt curve would allocate and guarantee a small amount of bandwidth to
> each queue. If some of those classes have time sensitive traffic, you
> could define a dilinear rt curve which would help jump those packets in
> front of the others.  Then, with the ls curves, you could allocate spare
> bandwidth.

I'll have to dig out my old tests - I guess I did try to do this - but 
may have failed :-)

> Of course, with five full queues firing
> full sized packets at 256kbit one can expect almost 250ms latency and
> can only guarantee 50 kbits.

I recall that I did manage to set things up so my rt was not delayed by 
more than one bulk packet in the bulks backlogged test.

> Good luck - John

Thanks - I'll need it :-)

Andy.

Re: prio + policing filter on ingress?

[Andrew Beverley]

On Thu, 2011-12-15 at 20:48 +0000, Andy Furniss wrote: 
> Andrew Beverley wrote:
> 
> >
> > Well according to a question just posted to the (new) LARTC mailing
> > list,
> 
> Interesting - where's the new list please?

Well, sort of new, it was created recently by Niccolò Belli who wanted
to restart the LARTC mailing list, so he started his own and added as
many people from the old list as he could find.

It's had a pretty slow start, but there's been a few questions. Some
would rather see it hosted at vger (including me), but in all honesty
there didn't seem to be a huge amount of interest in restarting it at
all.

http://lists.linuxsystems.it/listinfo/lartc

Andy

LARTC mailing list [was: Re: prio + policing filter on ingress?]

[Niccolò Belli]

Il 19/12/2011 10:53, Andrew Beverley ha scritto:
> On Thu, 2011-12-15 at 20:48 +0000, Andy Furniss wrote:
>> Andrew Beverley wrote:
>>
>>>
>>> Well according to a question just posted to the (new) LARTC mailing
>>> list,
>>
>> Interesting - where's the new list please?
>
> Well, sort of new, it was created recently by Niccolò Belli who wanted
> to restart the LARTC mailing list, so he started his own and added as
> many people from the old list as he could find.
>
> It's had a pretty slow start, but there's been a few questions. Some
> would rather see it hosted at vger (including me), but in all honesty
> there didn't seem to be a huge amount of interest in restarting it at
> all.
>
> http://lists.linuxsystems.it/listinfo/lartc
>
> Andy

I believe there is still some interest, consider there are less than 30 
members in the 'new' lartc mailing list, some of them which probably 
changed their e-mail address.
Anyway I think we should just try to start a new one and see how well it 
goes, considering:
- most people want to keep the actual "LARTC" name
- most people prefer vger, so we should try there first and keep the 
personal server as a backup option
- the content in the LARTC website is under an open license, so we could 
copy-paste it and create a wiki where users can keep it updated. Same 
question here: I can host it without problems but is there a better 
suited alternative?

Cheers,
Niccolò

Re: LARTC mailing list [was: Re: prio + policing filter on ingress?]

[John A. Sullivan III]

On Mon, 2011-12-19 at 12:25 +0100, Niccolò Belli wrote:
> Il 19/12/2011 10:53, Andrew Beverley ha scritto:
> > On Thu, 2011-12-15 at 20:48 +0000, Andy Furniss wrote:
> >> Andrew Beverley wrote:
> >>
> >>>
> >>> Well according to a question just posted to the (new) LARTC mailing
> >>> list,
> >>
> >> Interesting - where's the new list please?
> >
> > Well, sort of new, it was created recently by Niccolò Belli who wanted
> > to restart the LARTC mailing list, so he started his own and added as
> > many people from the old list as he could find.
> >
> > It's had a pretty slow start, but there's been a few questions. Some
> > would rather see it hosted at vger (including me), but in all honesty
> > there didn't seem to be a huge amount of interest in restarting it at
> > all.
> >
> > http://lists.linuxsystems.it/listinfo/lartc
> >
> > Andy
> 
> I believe there is still some interest, consider there are less than 30 
> members in the 'new' lartc mailing list, some of them which probably 
> changed their e-mail address.
> Anyway I think we should just try to start a new one and see how well it 
> goes, considering:
> - most people want to keep the actual "LARTC" name
> - most people prefer vger, so we should try there first and keep the 
> personal server as a backup option
> - the content in the LARTC website is under an open license, so we could 
> copy-paste it and create a wiki where users can keep it updated. Same 
> question here: I can host it without problems but is there a better 
> suited alternative?
<snip>
As someone who is strictly an end user with no kernel development skills
whatsoever, I would be delighted to see a user list again rather than my
having to spam the developers with all my silly questions and without me
deleting dozens of patch notifications.

On the other hand, LARTC seems to be such a complicated and not always
well documented project that I wonder how much help can be rendered if
the developers are not on the list - John

Re: LARTC mailing list [was: Re: prio + policing filter on ingress?]

[Andrew Beverley]

On Mon, 2011-12-19 at 12:25 +0100, Niccolò Belli wrote:
> Il 19/12/2011 10:53, Andrew Beverley ha scritto:
> > On Thu, 2011-12-15 at 20:48 +0000, Andy Furniss wrote:
> >> Andrew Beverley wrote:
> >>
> >>>
> >>> Well according to a question just posted to the (new) LARTC mailing
> >>> list,
> >>
> >> Interesting - where's the new list please?
> >
> > Well, sort of new, it was created recently by Niccolò Belli who wanted
> > to restart the LARTC mailing list, so he started his own and added as
> > many people from the old list as he could find.
> >
> > It's had a pretty slow start, but there's been a few questions. Some
> > would rather see it hosted at vger (including me), but in all honesty
> > there didn't seem to be a huge amount of interest in restarting it at
> > all.
> >
> > http://lists.linuxsystems.it/listinfo/lartc
> >
> > Andy
> 
> I believe there is still some interest, consider there are less than 30 
> members in the 'new' lartc mailing list, some of them which probably 
> changed their e-mail address.
> Anyway I think we should just try to start a new one and see how well it 
> goes, considering:
> - most people want to keep the actual "LARTC" name
> - most people prefer vger, so we should try there first and keep the 
> personal server as a backup option

Agreed with all the above.

VGER postmasters: can we try a new LARTC list at VGER please?

> - the content in the LARTC website is under an open license, so we could 
> copy-paste it and create a wiki where users can keep it updated. Same 
> question here: I can host it without problems but is there a better 
> suited alternative?

Transferring all the LARTC documents to a wiki would be good, as that
would allow people with their own areas of expertise to update the
relevant parts.

However, not sure where the best place to host it would be though. It
needs to be somewhere that can easily be found in place of the old lartc
website. Maybe somewhere in linuxfoundation.org? That's where most of
the other networking information seems to be.

Andy

Re: LARTC mailing list

[David Miller]

From: Andrew Beverley <andy@andybev.com>
Date: Mon, 19 Dec 2011 17:11:52 +0000

> VGER postmasters: can we try a new LARTC list at VGER please?

I've created lartc@vger.kernel.org, enjoy.

Re: LARTC mailing list

[Niccolò Belli]

Il 19/12/2011 20:59, David Miller ha scritto:
> From: Andrew Beverley<andy@andybev.com>
> Date: Mon, 19 Dec 2011 17:11:52 +0000
>
>> VGER postmasters: can we try a new LARTC list at VGER please?
>
> I've created lartc@vger.kernel.org, enjoy.

A-W-E-S-O-M-E, thank you so much!

We really need to find a place for the wiki now :)

Niccolò

Re: LARTC mailing list

[Andy Furniss]

David Miller wrote:
> From: Andrew Beverley<andy@andybev.com>
> Date: Mon, 19 Dec 2011 17:11:52 +0000
>
>> VGER postmasters: can we try a new LARTC list at VGER please?
>
> I've created lartc@vger.kernel.org, enjoy.

Great news, thank you.