[e2e] Packet dropping

[David P. Reed]

Dropping the new packet slows the current TCP congestion control 
algorithm's response, leading to slower and slower clogged Stevens' 
pipes, and a long time to recover.

Making the control loop for congestion faster end-to-end is a real-time 
problem embedded in non-real-time data transfers, and it affects overall 
performance.

Craig Partridge 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
> recover from.
>
> Craig
>
>
> 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).
>>
>> Any thoughts?
>>
>> Khaled
>>     
>
>