Re: [PATCH, untested] Support for PPPOE on SMP

Jamal Hadi writes:

So what about packet being loss? Wouldnt that ensure reordering?

Please explain.  What pattern of loss possibly results in one packet
being inserted in the stream ahead of another?

Here's loss:		1 2 4 5 6

Here's reordering:	1 2 4 3 5 6

Loss preserves ordering.  To get misordering, you have to
intentionally hold onto a message and reinsert it later.  What I've
been pointing out is that the 802 MAC layer *does not* permit
misordering (or duplication, for that matter).  Loss, reordering, and
duplication are all separate errors.

And there is no such thing as a lossless wire.

True, but not relevant.  When you put packets onto a wire, you must do
so in a particular order -- it's not possible to put more than one
packet at a given time on a single wire.  It's also not possible for
the receiver to get them in a different order than you sent them.
They're essentially "single file" on that wire.

PPP relies on this fact (albeit for serial wires) as part of its
protocol definition (RFC 1661):

1.  Introduction

   The Point-to-Point Protocol is designed for simple links which
   transport packets between two peers.  These links provide full-duplex
   simultaneous bi-directional operation, and are assumed to deliver
   packets in order.  It is intended that PPP provide a common solution
[...]

In addition, the 802 MAC layer cannot reorder packets, so there is no
conflict here.  Although there are many design mistakes in PPPoE, this
just is not one of them.

There is a design problem here, but it's not PPPoE's.

PS:- Paulus i wasnt preaching getting rid of ppp/pppoe although its
a nice thouhgt. More fix linux pppd and pppoe ;->

Believe me, the IETF working group didn't want PPPoE, either.  It
dropped from outer space.  The only reason it was published as
"Informational" is that it had already been deployed (before anyone
bothered to talk to the folks who are responsible for the PPP
standards), and thus somebody might want to know about it.

If we could have killed it, we would have.

-- 
James Carlson                                  [off-list ref]

James Carlson writes:

Jamal Hadi writes:

quoted

So what about packet being loss? Wouldnt that ensure reordering?

Please explain.  What pattern of loss possibly results in one packet
being inserted in the stream ahead of another?

Rusty asked me today what protocols there were that coped with packet
loss but couldn't cope with reordering.  I couldn't think of any.  Do
you know of any examples?

Regards,
Paul.

On Fri, 27 Jun 2003 22:12:13 +1000 (EST)
Paul Mackerras [off-list ref] wrote:

James Carlson writes:

quoted

Jamal Hadi writes:

quoted

So what about packet being loss? Wouldnt that ensure reordering?

Please explain.  What pattern of loss possibly results in one packet
being inserted in the stream ahead of another?

Rusty asked me today what protocols there were that coped with packet
loss but couldn't cope with reordering.  I couldn't think of any.  Do
you know of any examples?

Does LLC allow for re-ordering?

On Fri, 27 Jun 2003, James Carlson wrote:

Jamal Hadi writes:

quoted

So what about packet being loss? Wouldnt that ensure reordering?

Please explain.  What pattern of loss possibly results in one packet
being inserted in the stream ahead of another?

Here's loss:		1 2 4 5 6

Here's reordering:	1 2 4 3 5 6

Loss preserves ordering.  To get misordering, you have to
intentionally hold onto a message and reinsert it later.  What I've

And thats what i was implying.
In your above example:

1 2 4 5 6
If the entity above the wire cared about packet 3 there will be a
retransmit. so it becomes:

1 2 4 5 6 3

I suppose if you can ensure ordering with a retransmit by having a window
of size 1 clocked by ACKs.


cheers,
jamal