Re: Question the other way round:
Vimal <[email protected]> Sat, 16 Nov 2013 08:43:56 -0800
| Newsgroups | gmane.network.end2end |
|---|---|
| Message-ID | <CAK3Ji13XzAwJVgVHRJ+7yUyma_Z=Nh-W_inP=wn1fu0CG_3=1g@mail.gmail.com> |
I am not sure I entirely followed your previous email, but you seem to point out that buffers are inevitable. Yes, I think buffers are necessary for good utilisation as arrivals are hard to predict. In an ideal world the buffer would be sized just about right to fully utilise link (assuming that is something we care about). As you pointed out rightly -- so far, again as far as I am aware -- we have designed congestion control algorithms for a specific objective (which seems hard enough). From an optimisation perspective, the moment you have two objectives, it is not clear, and not meaningful to talk about "optimising" anything. It exposes a tradeoff -- I don't think there is hope of finding a universal scheduling algorithm that works best for all objectives. What is the 'right' tradeoff? I have no idea. You mentioned buffer sizing for low RTT and high throughput. I think achieving a particular objective might also need cooperation from end-hosts. Also, instead of one size fits all, you can have a hierarchical scheduler setup: - At the top level, divide bandwidth in some fashion between class A and B (say equally) - Class A has small buffers. - Class B has large buffers. - Flows that need low delay are directed to class A's queues. - Flows that need high throughput are directed to class B's queues. This way you can get a "bit" of both objectives while ensuring each class gets a certain bandwidth guarantee. On 16 November 2013 04:26, Detlef Bosau <[email protected]> wrote: > One quick remark: As Vimal said, Len Kleinrock assessed his queueing > systems with ONE metric. > > It may well be, that different flows have different objectives. One flow > may prefer a short RTT, another one high throughput. Both is lumped > together by using "the" one and only metric. Perhaps, a buffer for a > wireless link will be made larger, when we want a high average > throughput, and smaller when we want a smal RTT. > > With VJCC we first feed the net. Nearly regardless of the consequences. > > And afterwards, we try to escape the home made disaster. > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistraße 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > [email protected] http://www.detlef-bosau.de > > -- Vimal