Re: network nicety

Re: network nicety

[Chris Wedgwood]

On Thu, Oct 08, 1998 at 12:27:52PM -0400, Feuer wrote:

> How about telling me how, where, etc.

It depends on exactly what you want to do... and what you want to
achieve.

If your on a dial-up to an ISP somewhere, and you want better telnet
throughput at the cost of ftp throughput, chances are - you can't do
much at all, because the changes need to be done at the ISP end.

For QoS stuff, CONFIG_NET_SCHED=Y, get Alexy's ip-route and other
stuff from ftp://ftp.inr.ac.ru/ip-routing/ (as mentioned in the docs
for CONFIG_NET_SCHED) and read up on the relevant papers...
http://www-nrg.ee.lbl.gov/floyd/ is probably one place to start,
especially for CBQ which is currently occupying much of my time.

Note, this is all very much more complicated than it first appears,
there is much science and math involved to truly understand much of
what goes on.

> You are calling spam blockers rude while you are sending spam? By
> the way, I don't want to see anything from you or anything related
> to you in my mailbox.  Any such action will be considered a
> denial-of-service attack on my system.

Don't be an obnoxious little prick. Where or when did I say I was
sending out spam?




-cw

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: network nicety

[Riley Williams]

Hi Alan.

On Fri, 9 Oct 1998, Alan Cox wrote:

 >> Sure - you're saying that just because you're downloading an
 >> application for a customer, nobody else should be able to use that
 >> link - and I have to say that I disagree with that viewpoint.

 > TCP/IP doesnt claim to be fair

True, but irrelevant - whether or not TCP/IP is fair has no bearing on
whether the users should show the sort of greed implied by the message
I replied to...

 >> IMHO, the fact that an FTP transfer will automatically grab 100% of
 >> the bandwidth of one's primary link given the slightest chance can
 >> only be bad - and the same applies to any other protocol. What I'd
 >> like to see is some form of bandwidth limiting system which prevents
 >> any one protocol from grabbing more than 90% of the bandwidth to
 >> itself, but which allows any protocol to use all otherwise unused
 >> bandwidth if it needs it, but automatically relinquishes the excess
 >> bandwidth as soon as anything else needs it.

 > Its called CBQ and Linux 2.1.x supports it.

Two points here.

 1. It's good to know that such a thing exists.

 2. Does Linux apply it automatically when the remote end is also a
    Linux system? If not, there's little incentive for others to
    also support it.

 > Don't expect ISP end user ports to support it in the next 5 years
 > however, $10/month customers arent worth the CPU cost of such
 > things

Somehow, that doesnae surprise me...

Best wishes from Riley.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: network nicety

[Alan Cox]

>  2. Does Linux apply it automatically when the remote end is also a
>     Linux system? If not, there's little incentive for others to
>     also support it.

It isnt automatic. CBQ is a policy driven system. You get to set policy
according to local needs. Thats one of the problems you need to then
talk to the other end to pass policy (and also potentially along paths
packets are taking).

If you control both directions from a routing point then CBQ can
be a huge help as can other flow control schemes like RED (random
early drop - a simple scheme that punishes the highest bandwidth
users when congestion is occuring)

Alan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: network nicety

[Joel Jaeggli]

On Fri, 9 Oct 1998, Alan Cox wrote:

> > Sure - you're saying that just because you're downloading an
> > application for a customer, nobody else should be able to use that
> > link - and I have to say that I disagree with that viewpoint.
> 
> TCP/IP doesnt claim to be fair
> 
> > IMHO, the fact that an FTP transfer will automatically grab 100% of
> > the bandwidth of one's primary link given the slightest chance can
> > only be bad - and the same applies to any other protocol. What I'd
> > like to see is some form of bandwidth limiting system which prevents
> > any one protocol from grabbing more than 90% of the bandwidth to
> > itself, but which allows any protocol to use all otherwise unused
> > bandwidth if it needs it, but automatically relinquishes the excess
> > bandwidth as soon as anything else needs it.

If you're running RED enabled router images your tcp connections should
rate adjust quite well provided they lose enough packets. RED unlike most
diffserv/qos schemes you might choose to implement is quite cpu efficient
in terms queue management. Now that Van has moved  from lbnl to cisco
maybe we'll see some more schemes with wider adoption.
 
> Its called CBQ and Linux 2.1.x supports it. Don't expect ISP end user
> ports to support it in the next 5 years however, $10/month customers arent
> worth the CPU cost of such things
> 
> Alan
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
> 

-------------------------------------------------------------------------- 
Joel Jaeggli				       joelja@darkwing.uoregon.edu    
Academic User Services			     consult@gladstone.uoregon.edu
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/