PPP Encapsulated in GRE with IP Precedence headers

PPP Encapsulated in GRE with IP Precedence headers

[Ray Van Dolson]

Background:
We are using Poptop + PPP/MPPE and are running some VoIP applications
over this and want to "prioritize" the voice traffic.  This is easily
done in a non-tunnelled environment because the voice protocol we are
using (RTP) sets the "Expedite Immediately" flag in the DSCP headers of
the IP packet.  Cisco routers and iptables/tc can be made to flag on
this and do the "right" thing (ie: prioritize).

However, when Poptop encapsulates the PPP frames into GRE, it does not
put any sort of DSCP flags in the corresponding GRE IP packets.  We are
hoping to have Poptop/pptpclient modified to unpack the PPP frame it
receives, examine the IP packet within and copy any DSCP flags into the
GRE IP packet.  Thus if the IP packet in question was RTP, the
resulting GRE packet would have the High Precedence DSCP flag set.

The question is, does PPP go haywire if packets start arriving out of
order as a result of this?  Would we end up being worse-off than if we
didn't do this at all?  I can see how a GRE-only tunnel would handle
this just fine, but the added layer of PPP makes me think any sort of
re-ordering of the GRE packets would break the PPP connection.

Thoughts?  Flames?

-- 
Ray Van Dolson
Linux/Unix Systems Administrator
Digital Path, Inc.

Re: PPP Encapsulated in GRE with IP Precedence headers

[James Carlson]

Ray Van Dolson writes:
> However, when Poptop encapsulates the PPP frames into GRE, it does not
> put any sort of DSCP flags in the corresponding GRE IP packets.  We are
> hoping to have Poptop/pptpclient modified to unpack the PPP frame it
> receives, examine the IP packet within and copy any DSCP flags into the
> GRE IP packet.  Thus if the IP packet in question was RTP, the
> resulting GRE packet would have the High Precedence DSCP flag set.

That's a bit icky, but I can see why you'd want to do it.

The "right" architectural answer would be to have PPP itself get the
IP DSCP information and use it to prioritize the traffic, and express
the priority in some implementation-dependent way down to the layer
that does the GRE/IP encapsulation.

> The question is, does PPP go haywire if packets start arriving out of
> order as a result of this?  Would we end up being worse-off than if we
> didn't do this at all?  I can see how a GRE-only tunnel would handle
> this just fine, but the added layer of PPP makes me think any sort of
> re-ordering of the GRE packets would break the PPP connection.

If it's just plain IP over PPP, and you're not negotiating any of MP,
ECP, CCP, VJ Header Compression, or Robust Header Compression, then
you should be able to get away with this.  The above protocols,
though, generally assume strict ordering (it is point-to-point,
right?) and will fall apart if that's compromised.

Since you're violating layering anyway, though, you could also just
intercept the initial negotiation messages and force any "unusual"
features off.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: PPP Encapsulated in GRE with IP Precedence headers

[Ray Van Dolson]

> If it's just plain IP over PPP, and you're not negotiating any of MP,
> ECP, CCP, VJ Header Compression, or Robust Header Compression, then
> you should be able to get away with this.  The above protocols,
> though, generally assume strict ordering (it is point-to-point,
> right?) and will fall apart if that's compromised.

Unfortunately we are using MPPE, so perhaps this solution is not as viable as
I thought it would be.  Thanks for the clarification.

Re: PPP Encapsulated in GRE with IP Precedence headers

[James Carlson]

Ray Van Dolson writes:
> > If it's just plain IP over PPP, and you're not negotiating any of MP,
> > ECP, CCP, VJ Header Compression, or Robust Header Compression, then
> > you should be able to get away with this.  The above protocols,
> > though, generally assume strict ordering (it is point-to-point,
> > right?) and will fall apart if that's compromised.
> 
> Unfortunately we are using MPPE, so perhaps this solution is not as viable as
> I thought it would be.  Thanks for the clarification.

I did say "generally."

If the actual compressor/encryptor is able to deal with multiple
session states for the separate flows that can be scheduled
independently, then this could still work.

But I don't see that MPPE (in particular) can do that.  It has just
one 'coherency count' field, and doesn't seem to maintain multiple
histories.  Unless there's buffering and reordering done at the
receiver (which would pretty much nullify any goodness you might hope
to get from priority queuing), I think you're sunk.

An alternate path that might do the job would be to set up multiple
parallel PPP sessions (one for each distinct ordering class), and
direct the traffic on entry from IP into PPP based on DSCP.  Though it
looks feasible from the protocol level, that might take some doing
depending on the implementations involved.

(In practice, I haven't been any too impressed with prioritization
schemes that do more than just make sure that network control traffic
has highest priority.  And even then there are some interesting
failure modes ...)

-- 
James Carlson                                 <carlsonj@workingcode.com>