> IPv6 is the answer. anyone want to wait for the Internet to implement that?
> :)
It does have some diffserv bits, ie the 4 bit priorority value, but I
don't think It's the solution and it's unlikely to be used on the
commidity internet anytime soon from the look of things.
> What I can see happening quickly is for the sending app (say wuftpd) to burst
> at the start of the transfer (to find the max bandwith it has for the
> connection.) Then to backoff a certain percentage.
Slow-start is the right way to do things... and is actually a requirement
to be rfc 1122 compliant see rfc 2001 ( TCP Slow Start, Congestion
Avoidance, Fast Retransmit, and Fast Recovery Algorithms) for a
discussion of the definitions. a proply written implemntation should ramp
up very fast and be a good citizen when it comes to conjestion. After all
you only have to lose one packet to cuts the streams rate in half...
joelja
> ---- As written by Riley Williams:
> >
> > Hi Simon.
> >
> > On Thu, 8 Oct 1998, Simon Kenyon wrote:
> >
> > > On 08-Oct-98 Bob Lanning wrote:
> >
> > >> It is very hard to implement something like this. The data
> > >> channel for ftp has no real identification in it. The best way of
> > >> doing this is in the application.
> >
> > > dare i suggest that *not* being able to identify traffic is good
> > > it might only be an ftp to you, but to me it might be that upgrade
> > > of some software that will rescue me from hackers, or a new release
> > > for a customer who is threatening to sue, or ...
> >
> > > you get my point (maybe)
> >
> > 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.
> >
> > 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.
> >
> > 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/
> >
>
>
> --
> Robert Hajime Lanning Navigation Technologies
> Unix Systems Administrator 740 E. Arques Ave.
> (408) 617-5059 Sunnyvale, CA 94086
> lanning@fhda.edu USA
> lanning@kewltech.com lanning@navtech.com
>
> -
> 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/