8 replies to this topic

[Apprentice123]

How is the congestion control, when the buffer is finite, in an exchange of packets between sender and recipient?

[Apprentice123]

What would be the congestion control ? The sender should limit the rate at which it sends traffic to your connection so as to take control of congestion?

[dargueta]

Dropping packets is usually the way it works, though that's more of the router's job. Is there any reason why you replied to your own question?

[Apprentice123]

dargueta said:

Dropping packets is usually the way it works, though that's more of the router's job. Is there any reason why you replied to your own question?

I asked if what I think is correct

[dargueta]

That's not really the way it works. The server is supposed to ignore/delay requests as necessary to throttle the traffic back.

[Apprentice123]

dargueta said:

That's not really the way it works. The server is supposed to ignore/delay requests as necessary to throttle the traffic back.

Is there any algorithm to control congestion?

[dargueta]

FIFO, I guess. Keep a queue of queries of some predetermined size, and send an error message back to the ones that don't fit in the queue.

[zoranh]

Limiting send rate is typically implemented using Leaky Bucket algorithm. In that case, sender is responsible to ensure that bucket does not overflow, or otherwise data will be lost. This algorithm is not perfect, because it still does not guarantee that congestion will not occur.

If congestion occurs at receiver (e.g. it is a server with many socket connections), then control can be implemented there - receiver is expected to control amount of data sent by the remote node. For example, receiver sends allowed amount of data to each of the senders, and senders may not send more than that until ordered so.

[Apprentice123]

zoranh said:

Limiting send rate is typically implemented using Leaky Bucket algorithm. In that case, sender is responsible to ensure that bucket does not overflow, or otherwise data will be lost. This algorithm is not perfect, because it still does not guarantee that congestion will not occur.

If congestion occurs at receiver (e.g. it is a server with many socket connections), then control can be implemented there - receiver is expected to control amount of data sent by the remote node. For example, receiver sends allowed amount of data to each of the senders, and senders may not send more than that until ordered so.

OK. The best control is to use end-to-end ? In which, TCP reduces the window size according to the packet loss ?
See if my thinking is correct:
If a TCP sender realizes there is little congestion on the path between him and the recipient will increase its sending rate, if realize exist congestion on the way will reduce its sending rate. Was that it?