[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