[e2e] Packet dropping

[Roman Pletka]

Hi Khaled,


I did some research on the impact of dropping packets from the front of a queue 
that might be of interest for you. It was related to the approximative longest 
queue drop algorithm and shows how packet drops from the front of a queue can 
help TCP to maintain a certain bandwidth share in presence of a non-responsive 
source. Have a look at section 3 in the report:

http://ecwww.eurecom.fr/~pletka/publications/report-pletka-99.pdf

Best regards,
Roman




Khaled Elsayed wrote:
> 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).
> 
> Any thoughts?
> 
> Khaled
> 
> 

-- 
---------------------------------------------------------------------------
Dr. Roman Pletka                                            roman at pletka.ch
Meilibachweg 11                                    Private: +41 43 244 6654
CH-8810 Horgen                                      Mobile: +41 79 293 6948
---------------------------------------------------------------------------