[e2e] Packet dropping

Craig Partridge craig at aland.bbn.com
Wed May 2 10:36:30 PDT 2007


In message <62857.93128.qm at web25415.mail.ukl.yahoo.com>, Saqib Ilyas writes:

>I would expect for non-real-time protocols such as FTP that if the packet at t
 >he head of the queue is dropped, there'd be several duplicate acks which coul
 >d trigger congestion control. 
>  Regards

I understand that point.

My reasoning may be flawed, but just to dig myself deeper.  The
question was what's the best way for the queue to drain?

So let's consider ten packets 0-9 in flight at sender, router and receiver

In the scenario, the router is about to receive buffer 9

    Sender's buffer		Router Buffer		Receiver Buffer

    012345679			012345679

If it drops 9, then in one RTT we'll have

    Sender's buffer		Router Buffer		Receiver Buffer

    9abcdefghi			<some packets>

If it drops 0, then in one RTT with fast retransmit we'll have

    Sender's buffer		Router Buffer		Receiver Buffer
    012345679			0			123456789


In either case the router queue looks similar -- the issue is which wins
going forward.  And it wasn't immediately clear to me that fast retransmit
was better.  If we drop 0, we're in fast retransmit and about to enter
slow start on packet a.  If we drop 9, we're about to fire off dupe acks
on a-i, and will enter fast retransmit on packet b.

Craig


More information about the end2end-interest mailing list