LARTC - Dec 2001 - Re: SFQ

re: Subject: [LARTC] SFQ working
 ...
 > > Here different flows are distinguished by source & dest addresses
and
 > > source port.
 > > 
 > > Is this right?
 > 
 > Exactly.
 > 
 > Regards,
 > 
 > bert

I think this is not quite right.
Also dest port, right?
And of course protocol.
And of course lower level (eth) protocol - above applies to IPv4.

and re: > Subject: Re: [LARTC] sfq as solution to "Small ISP
problems"
 > >  > 1: SSH - to be realtime always.
 > > I don''t think you want this to always be high prio - that
includes scp.
 > 
 > your''e right, only the real ssh traffic..

How do you propose to tell the difference between ssh and scp?

 ...
 > > I think what you really want is to prevent large flows from unfairly
 > > impacting small ones, and that''s what sfq does.  Try it and
see
 > > whether you get the behavior you want.
 > 
 > Oki, I tried it. I defined two classes. "all_in" and
"all_out".
 > I have 2Mbit full duplex so just to be sure my que isn''t ending
up in the
 > g703 "modem" I defined the classes to 1,900Mbit downstream and
1,000Mbit
 > upstream.
 > Put SFQ on both classes and tested under heavy load..
I don''t understand what these classes are for or what the 2Mbit above
has to do with the 2 and 1 Gbit above.

 > > If you''re really in the first situation where you just want
to give
 > > equal service to all who are requesting it then what you really want
 > > is a slight variant of sfq.  If you look at the code you''ll
see a hash
 > function that takes into consideration source and destination ip
 > 
 > What code exactly ? I am currently using the cbq.init script version 0.6.2
.
Not that code, but kernel source for sfq in net/sched/sch_sfq.c
 > > address and port and maybe other stuff.  All you want to do is remove
 > > all but the source IP (and then perhaps do what you can to prevent
 > > source forgery!).  That will give fair service among all source IP
 > > addresses.

 > Take a look at this:
 > 
 > Right now my bandwidth looks like this:
 > 
 > Total Rates: 	2170.6 kbits/s
 > 			517.6 packets/sec
 > 
 > Incoming rates:	1769.4 kbits/s
 > 			261.4 packets/sec
 > 
 > Outgoing rates:	401.2 kbits/sec
 > 			256.2 packets/sec
 > 
 > Well, we have a full duplex 2Mbit connection so this should not be a
 > problem.
 > Eventhough, we,  based on a 265 packets test, have 28% packet loss witch
is
 > not good.

If you''re not using up your bandwidth I don''t see why
you''re dropping.
Do you understand that?

On Tue, Dec 11, 2001 at 11:50:12PM -0800, Don Cohen wrote:
>  > > Here different flows are distinguished by source & dest
addresses and
>  > > source port.
>  > > 
>  > > Is this right?
>  > 
>  > Exactly.
>  > 
>  > Regards,
>  > 
>  > bert
> 
> I think this is not quite right.
> Also dest port, right?
	 case __constant_htons(ETH_P_IP):
        {
                struct iphdr *iph = skb->nh.iph;
                h = iph->daddr;
                h2 = iph->saddr^iph->protocol;
                if (!(iph->frag_off&htons(IP_MF|IP_OFFSET)) &&
                    (iph->protocol == IPPROTO_TCP ||
                     iph->protocol == IPPROTO_UDP ||
                     iph->protocol == IPPROTO_ESP))
                        h2 ^= *(((u32*)iph) + iph->ihl);
                break;
	}

In case of ipv4:
	destination address
	source address
	ip protocol 
	source port/dest port tuple

I missed the fact that the first 4 octects of the IP sub-protocol header
were include in (u32).
> and re: > Subject: Re: [LARTC] sfq as solution to "Small ISP
problems"
>  > >  > 1: SSH - to be realtime always.
>  > > I don''t think you want this to always be high prio -
that includes scp.
>  > 
>  > your''e right, only the real ssh traffic..
> 
> How do you propose to tell the difference between ssh and scp?
Read the HOWTO. Scp doesn''t set the ''minimum delay''
flag.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
Trilab                                 The Technology People
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
''SYN! .. SYN|ACK! .. ACK!'' - the mating call of the internet