[e2e] TCP out of order

[Michael Welzl]

Hi,

Thanks a lot for the explanation; I wasn't aware of that.

Just out of curiosity: doesn't this pose a problem for the packet pair
approach? It seems as though this was a more or less deterministic
behaviour ... which means that packet pair more or less won't work at
all - so after a while, your packet pair tool would need to switch to a
flooding approach like the original one proposed by Bolot.

I didn't notice any of these problems mentioned in the papers on packet
pair. I may have overlooked it or plainly forgotten about it ... but it
strikes me as somewhat odd.

Cheers,
Michael


> Michael,
> 
> The store time for the larger packet puts it at a disadvantage in being
> placed into a forward queue.  Packets may not be processed immediately so
> should the completion of a larger packet just miss a process window, a
> trailing smaller packet then has a chance of getting placed ahead as there
> are places within packet buffering that may violate a packet sequence order.
> A descriptor ring could be one such area.
> 
> Doug
> 
> > > Note that you can get very consistent packet reordering even if the
> > > speed-of-light delay difference is zero and the circuit bandwidths
> > > are identical, if the packets being generated are sometimes different
> > > sizes.  That is, if you send a big packet followed by a small
> > > packet, the small packet will always catch up to and pass the big
> > > packet if they traverse enough store-and-forward hops.
> >
> > Forgive my ignorance - but: why?
> >
> > Michael
>