Subject: ML without ML headers - requirements? suggestions?

From: "John R. Martz" <[email-masked]>
Date: Wed, 25 Aug 1999 11:21:36 -0400

Folks,

Another aspect of multilink I'm not totally clear on is the usage of the ML headers. Going to post
what I think I know to allow someone to set me straight if I've got it wrong.

(1) A ML header should not be sent/received if you haven't enabled ML. (If you do allow ML ... do
not Cfg-Ack the peer's MRRU option  ... should you discard any packets the peer sends with a ML
header? Seems so ... )

(2) If ML is enabled, the use of the ML is completely optional. You should use them, but the RFC
doesn't require you to do this. (????)

Bad things that can happen if you do NOT always use ML headers include:
- Packets may arrive out of sequence. (You send A then B, but the peer received B before A).
- Peer will not be able to detect lost fragments for any packets sent to it with ML headers
- You won't be able to fragment packets (i.e. can't increase bandwidth when sending a "large" PPP
packet)

OTOH, since IP does it's own fragmentation I'm not sure how much of a loss it is to loose the
ability to fragment PPP packets. The loss of packet sequencing might be a problem for PPP protocol
negotiation. But then again, because the PPP protocol is request/response based, it's sorta self
sequenced, no?

Guess I'm not seriously proposing to implement ML without sending ML headers. But I am wondering
what part of the picture I'm missing here. And just what policy to follow re accepting/discarding
packets with ML headers.

Thanks,
-john martz ([email-masked])
IBM AS/400 TCP/IP PPP (and stuff)

---

From: James Carlson <[email-masked]>
Date: 25 Aug 1999 14:00:58 -0400

[email-masked] ("John R. Martz") writes:
> (1) A ML header should not be sent/received if you haven't enabled
> ML. (If you do allow ML ... do not Cfg-Ack the peer's MRRU option
> ... should you discard any packets the peer sends with a ML header?
> Seems so ... )

You should send LCP Protocol-Reject if you receive any packet that has
a protocol number you haven't agreed to receive.  This applies to MP
as well.

> (2) If ML is enabled, the use of the ML is completely optional. You
> should use them, but the RFC doesn't require you to do this. (????)

Right.  It's up to you.  You MUST be able to receive such data, but
whether or not you send it is your choice.  (Of course, with all such
choices, you need to have a good reason to do something other than
what the RFC says to do.)

> - You won't be able to fragment packets (i.e. can't increase
> bandwidth when sending a "large" PPP packet)

All true.  However, if you send something without the MP header, then
it won't be delayed by reassembly's lost-fragment detection algorithm
if there are drops at the peer.  That's the choice *you* must make.
It's not up to the standard to specify this, since it can't be
properly specified in all possible cases.

(Suppose there's a UDP protocol that doesn't care about packet
reordering but *does* care about delay variance caused by reassembly.
An system that uses this protocol could allow a socket-level flag to
be passed down through the IP layer into the driver to tell it to
avoid encapsulating those particular packets with MP headers.)

> OTOH, since IP does it's own fragmentation I'm not sure how much of
> a loss it is to loose the ability to fragment PPP packets.

It means a lot more to other protocols, of course.  IP fragmentation
has its own problems as well considering that a fair number of people
leave PMTU discovery enabled.

> The loss
> of packet sequencing might be a problem for PPP protocol
> negotiation. But then again, because the PPP protocol is
> request/response based, it's sorta self sequenced, no?

I'm not sure I understand the point there.  You certainly do *not*
want to send one PPP negotiation packet without MP headers on one link
and then another for the same state machine over a different link.
That would be a bad idea.  It's much better to choose a single link
and negotiate over that.

> Guess I'm not seriously proposing to implement ML without sending ML
> headers. But I am wondering what part of the picture I'm missing
> here.  And just what policy to follow re accepting/discarding
> packets with ML headers.

If you're referring to packets received with PPP protocol ID 003D when
you haven't specifically negotiated MRRU, you should Protocol-Reject
those.

Otherwise, you should generally do discard in accordance with section
4.1 of RFC 1990.  (Of course, any datagram implementation is free to
discard any datagram at any time.  But that's another topic ...)

-- 
James Carlson, System Architect                     <[email-masked]>
IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: "John R. Martz" <[email-masked]>
Date: Wed, 25 Aug 1999 14:47:01 -0400

> I'm not sure I understand the point there.

James,

I'm not so sure I had a point. <g>

What I was thinking was, "I don't see how you'd actually get packets out of sequence while doing PPP
negotiation because it's a request/response protocol. But OTOH I don't feel I completely understand
the PPP state machine, so maybe I'm missing something?"

> You certainly do *not*

Why is this a bad idea? Not tryiing to argue with you, I just don't see why it's a problem and I'd
really like to understand. This isn't something we'd considered doing before. I thought the NCP
negotiation could be over the virtual link/bundle and thus could end up going down any of the links
that had been bundled together.

Whether you send an IPCP packet over link A or link B they both should be processed by the same
state machine task on the remote peer, correct? By "sorta self-sequencing" I meant that PPP is
request/response. You send Cfg-Req and then wait for a response. You only resend the request if the
retry timer pops. And if you do resend, then the resent packet is identical to the sent packet so
there's practically speaking they can't be received "out of sequence". No?

What is that I am not seeing? Why should you ALWAYS use the MP headers when sending NCP packets over
multiple links in a bundle?

Thanks,

---

From: James Carlson <[email-masked]>
Date: 25 Aug 1999 18:04:10 -0400

[email-masked] ("John R. Martz") writes:
> What I was thinking was, "I don't see how you'd actually get packets
> out of sequence while doing PPP negotiation because it's a
> request/response protocol.

Not really.  There are timers running and, during Network phase, there
are any number of NCPs running simultaneously.

> But OTOH I don't feel I completely
> understand the PPP state machine, so maybe I'm missing something?"

The state machine isn't designed with that case in mind.  I *think*
the worst you'll do is end up not converging and drop the link.  But
I'm not sure and I'd have to think about it for a while.

> Why is this a bad idea? Not tryiing to argue with you, I just don't
> see why it's a problem and I'd really like to understand. This isn't
> something we'd considered doing before. I thought the NCP
> negotiation could be over the virtual link/bundle

It can, though it's rarely done that way.

> and thus could end
> up going down any of the links that had been bundled together.

No.  MP puts everything back into sequential order at the other end if
you do it over the bundle.  (Unless you try to run without sequencing
on individual links, then you're not really running over the bundle
itself.)

> Whether you send an IPCP packet over link A or link B they both
> should be processed by the same state machine task on the remote
> peer, correct? By "sorta self-sequencing" I meant that PPP is
> request/response.

No, it's not.  You're both sending Configure-Acks and receiving
Configure-Requests at the same time.

> You send Cfg-Req and then wait for a response. You
> only resend the request if the retry timer pops. And if you do
> resend, then the resent packet is identical to the sent packet so

Not always so.  It's perfectly legal to change the ID number when
doing a retransmit, and many implementations do that.

> What is that I am not seeing? Why should you ALWAYS use the MP
> headers when sending NCP packets over multiple links in a bundle?

It's obvious that it will slow down things on a phase transition --
for example, getting a PAP Authenticate-Request while you're still
waiting for an LCP Configure-Ack will cause you to ditch the PAP
message and force the peer to retransmit.

Otherwise, no, it's not immediately obvious to me why reordering is
considered to be absolutely fatal.  (And it is considered that way;
this was an important consideration in L2TP.)

I'll think about it ...