[e2e] Packet dropping
msaqibilyas74 at yahoo.co.uk
Wed May 2 04:44:24 PDT 2007
I would expect for non-real-time protocols such as FTP that if the packet at the head of the queue is dropped, there'd be several duplicate acks which could trigger congestion control.
Craig Partridge <craig at aland.bbn.com> wrote:
For non-real time, the answer I believe is drop the new packet.
Dropping the earlier packet (assuming the earlier packet has a lower
sequence number) is more likely to slow effective delivery of data
to the recipient and require a more complex set of retransmissions to
In message <463857A4.1020205 at gmail.com>, Khaled Elsayed writes:
>Given a per-connection queue that could potentially become full (or in
>case of RED, hits dropping threshold), an incoming packet arrives and
>finds the queue full. What would be the best policy:
>1) admit the new packet and drop one at the queue front
>2) drop the newly arriving packet.
>For real-time connections, it is intuitive that dropping at queue front
>would tend to result in better delay responses (this was already shown
>in an early paper by Yin and Hluchyj in IEEE Trans. Comm, June 1993).
>What about data/non-real time connections? Assume an FTP or HTTP session
>subject to above situation, would TCP behave better if packet is dropped
>from front or the new packet is dropped?
>I have no evidence but I tend to feel that if the congestion is
>persistent for some reasonable time, it would make more sense to deliver
>whatever is in the queue right now and drop the new ones at the expense
>of increasing overall avg. packet delay. If the congestion duration is
>small, it would not make a lot of difference (I guess).
Muhammad Saqib Ilyas
Department of Computer and Information Systems Engineering
NED University of Engineering and Technology, Karachi, Pakistan
Graduate Student, LUMS
Country Leader, INETA Pakistan
Microsoft Most Valuable Professional - C++
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your freeaccount today.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest