You make many interesting points...
>Reiner Ludwig wrote:
>I would also like to strongly promote clean designs, i.e., without layer
> violations. But to implement what I call inter-flow out-of-order delivery >
(as opposed to intra-
> flow out-of-order delivery, i.e., o-o-o delivery
> within a single flow), you do not need to have the link layer inspect IP
> headers.
> Instead, you could, e.g., run multiple logical link layers (one per flow)
> across a hop, and have IP distribute the packets onto those links based on
> port numbers. "one per flow" clearly does not scale, but for the first/last
> hop this shouldn't be a problem.
I agree with this idea.
I like the idea of decoupling the ARQ between different flows. Ordering does
not require persistence, or vice versa - yet many link protocols I have seen do
both of these or neither. I know there are protocols which do not, and
I am very interested in thinking about the implications of this. Have you
thought about the pros and cons of using parallel links with individual ARQ?
> I see highly persistent LL ARQ as independent from buffer memory. When some
> people hear highly persistent LL ARQ, they often think that this equals
> "buffering for ever". *No, it does not!* The queues need to remain
> appropriately small also with highly persistent LL ARQ.
> ///Reiner
I think this is where I begin to get confused? When the link carries some TCP and
some UDP flows. The UDP sources don’t simply stop because some of their
data is lost or waiting transmission in the link layer. Then, don’t you end up
with an excess of data queued at the link transmit interface. If the window/queue
is small, then you drop? Do you have to drop UDP preferentially to keep
TCP performance?
I wonder what happens when you have many many TCP flows all sharing then,
don’t you need to buffer a lot? or drop a lot?
Gorry Fairhurst
------------------------------
http://www.erg.abdn.ac.uk/users/gorry
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:25 EST