Re: Naive question on multiple TCP/IP channels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 4, 2015 at 3:47 PM, Phillip Hallam-Baker
<phill@xxxxxxxxxxxxxxx> wrote:

> I know that traditionally we have considered congestion control to be a per
> connection thing rather than per process or per user. Those don't exactly
> exist in the Internet model. But if we consider DDoS to be an extreme form
> of congestion, we have to look at the O/S implementing broader rate limiting
> anyway.

I'm not sure this scales in a useful manner...especially if you want
(for instance) to be able to read from your cloud/nas/etc at 'line
rate' but then limit access rates to other places because of 'dos'
concerns.

Policy for that is not going to be clear, or simple, or reasonable.

> If the case for multiple streams is better performance based on friendlier
> slow start parameters, maybe these should be allowed without the end run. If
> the net is surviving with people starting five streams instead of one, maybe
> the slow start parameters could start at five packets per destination host
> instead of one per connection. It would be a little more code to implement
> but speed is hardly an issue where its purpose is throttling anyway.

More connections means you may avoid the 'random early drop' problem
for some of your connections, right? Presuming somewhere between
src/dest there's a thinner pipe (or more full pipe) and RED/etc is
employed (or just queue drops in general), putting all your eggs in
one connection basket is less helpful than 5 connection baskets.

One connection (one traditional http/tcp connection) also means object
serialization gets you as well. (I think roberto alludes to this
above)





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]