2 replies to this topic

[Apprentice123]

When the buffer of the recipient fills, packet loss occurs. Correct ? To avoid this loss, we use the congestion control ?

[zoranh]

Congestion and buffer overflow are two distinct things, unless you're talking about buffers in routers.

Packet dropping policy was introduced in IPv6. Before that, it was usual that node (router) which detects congestion sends alert back down the connection to the source of the packets, informing the original sender that its packets are getting late and that it should reduce amount of data sent per unit of time. However, it turned out that alert packets were late as well, because congestion hit them too. But not only that they were late, they were producing additional traffic when quality of service is already poor. Latency itself was also a cause for overkill, because original sender would continue pumping data at high rate all until alert is finally delivered, which can take quite a long time, additionally decreasing network capabilities.

After long thinking, IPv6 finally made a clear-cut decision: packets that cannot be delivered are dropped. Full stop. No notification, no alerts, no added traffic, nothing. Just drop it and things will recover sooner than if you try to do anything smart. Note that this solution works in conjunction with TCP windowing algorithm. That works like this: at any point, node having TCP/IP connection is allowed to send packets from range K thru K+n-1. For each packet, acknowledge is expected. When acknowledge for packet K arrives, window moves to packets range K+1 thru K+n. If acknowledge does not arrive in due time, packet is resent. If acknowledge does not arrive after specified number of resends, connection is considered broken and it is dropped by the host.

So, knowing this, dropping packets policy looks quite good - every TCP/IP client will recover by trying to reconnect - it will probably fail to reconnect many times until congestion is resolved, but finally it will reconnect and continue communicating to remote host as before the congestion. On the other hand, UDP clients will suffer the same lack of acknowledges during congestion, and they will recover by themselves as they normally do, depending on implementation.

[Apprentice123]

zoranh said:

Congestion and buffer overflow are two distinct things, unless you're talking about buffers in routers.

Packet dropping policy was introduced in IPv6. Before that, it was usual that node (router) which detects congestion sends alert back down the connection to the source of the packets, informing the original sender that its packets are getting late and that it should reduce amount of data sent per unit of time. However, it turned out that alert packets were late as well, because congestion hit them too. But not only that they were late, they were producing additional traffic when quality of service is already poor. Latency itself was also a cause for overkill, because original sender would continue pumping data at high rate all until alert is finally delivered, which can take quite a long time, additionally decreasing network capabilities.

After long thinking, IPv6 finally made a clear-cut decision: packets that cannot be delivered are dropped. Full stop. No notification, no alerts, no added traffic, nothing. Just drop it and things will recover sooner than if you try to do anything smart. Note that this solution works in conjunction with TCP windowing algorithm. That works like this: at any point, node having TCP/IP connection is allowed to send packets from range K thru K+n-1. For each packet, acknowledge is expected. When acknowledge for packet K arrives, window moves to packets range K+1 thru K+n. If acknowledge does not arrive in due time, packet is resent. If acknowledge does not arrive after specified number of resends, connection is considered broken and it is dropped by the host.

So, knowing this, dropping packets policy looks quite good - every TCP/IP client will recover by trying to reconnect - it will probably fail to reconnect many times until congestion is resolved, but finally it will reconnect and continue communicating to remote host as before the congestion. On the other hand, UDP clients will suffer the same lack of acknowledges during congestion, and they will recover by themselves as they normally do, depending on implementation.

Thank you. But I am researching how to keep the congestion control using the idea of IPv4