[e2e] Packet dropping (Khaled Elsayed)

[David P. Reed]

Actually, TCP typically retransmits all the "out of order" packets you 
refer to Arjuna, because the sender won't know the receiver has received 
them unless SACK is working, an option that is not necessarily there.   
So the receiver can just drop all the out of order packets after a loss 
due to congestion without affecting throughput.

If you had a channel that could carry acknowledgements faster than the 
speed of light (a so-called ESP channel), of course you could invent a 
more interesting protocol than TCP.

But then you'd have to require that of every technology supported by 
TCP, and it's important to remember that TCP is a protocol for interop 
among heterogeneous technologies as its number one goal.   Super hyper 
optimized multihop subnets of uniform technology are best deployed as an 
underlay under TCP, and viewed as a link.

Arjuna Sathiaseelan wrote:
> My belief is as Craig said, for real-time packets - dropping the oldest
> packet would be the best solution - so it would be better to drop from the
> front of the queue, as most of the real-time packets (VoIP,
> videoconferencing) would be carried on UDP or DCCP - which do not require
> transport layer retransmissions. We need to note dropping real-time packets
> such as VoIP packets (carried by UDP or DCCP) would be more of a concern to
> the application layer rather than the transport layer.
>
> But for non-real time applications running over TCP - then I would prefer to
> see the new packet being dropped rather the oldest packet - as it would be a
> burden to the transport layer - since the transport layer has to buffer up
> all the out of order packets!
>
>
> Arjuna
>
> ------------------------------
>
> Message: 2
> Date: Wed, 02 May 2007 06:33:08 -0400
> From: Craig Partridge <craig at aland.bbn.com>
> Subject: Re: [e2e] Packet dropping
> To: Khaled Elsayed <kelsayed at gmail.com>
> Cc: end2end-interest at postel.org
> Message-ID: <20070502103308.0E521123842 at aland.bbn.com>
>
>
> 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
> ***************************************
>
>
>