Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt

From: Theimer Thomas <[email-masked]>
Date: Mon, 24 Jul 2000 14:50:38 +0200

Lou,

I just wanted to point out that there is another proposal on the table for end-end compression with MPLS that doesn't even require any changes to existing header compression mechanisms. All that is needed is carrying PPP over MPLS. You can then run any header compression offered by PPP end-end over MPLS (be it RFC 2508/2509 or robust HC or any other scheme). You can even run header compression over non-PPP links (e.g. Ethernet) if they can support MPLS.

The proposal is described in draft-theimer-tcrtp-mpls-00.txt. Its efficiency is much better than the "simple" end-end compression, but it is of course much more complex to process. However, since the compression is done very close to the source, this may still be acceptable (anyway, if the source is connected to the bottleneck link, it makes no difference if compression is one-hop or end-end). One might even link the state of VoIP calls to the compression context if desired. Eric's issue with not knowing higher layer protocols is also a non-issue with end-end compression.

My interpretation of this "consensus" thread is that there is more support for end-end compression than there is for one-hop compression with MPLS. Please correct me if I'm way off here.

Thomas
> -----Original Message-----
> From:	Lou Berger [SMTP:[email-masked]]
> Sent:	Friday, July 21, 2000 7:58 PM
> To:	[email-masked]
> Cc:	Lou Berger; Eric Gray; MPLS Mailing List (E-mail); 'George Swallow'
> Subject:	Re: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt
> 
> Eric,
>          The reason why you'd use the "one hop" approach over simple is 
> that the two compression schemes have vastly different efficiencies.  (17 + 
> 4 bytes/label versus 2 or 4 bytes. see slide 11 of my Adelaide 
> presentation.) IMO the "one hop" approach is best suited for those links in 
> the network that are very tightly constrained.  This may be on very slow 
> speed links or just "slower" speed links, where "slower" is limited by the 
> hardware being used.
> 
> I think your characterization below of an application is valid.  The VPN 
> example came in on a question of why there would ever be multiple 
> labels.  The case I was thinking about is were there is an inner label that 
> indicates VPN and an outer label that indicates an egress.  I didn't mean 
> to be evasive, I just didn't think it was that complicated.  I've also 
> heard mentioned using label stacking where, as with VPNS, the inner label 
> indicates an application session.
> 
> Lou
> 
> At 01:32 PM 7/21/00 -0400, Eric Rosen wrote:
> 
> >I  think the  basic question  is whether  there  is a  use for  a "one  hop"
> >compression strategy.
> >
> >Some  people  have mentioned  voice  traffic  as  an application  for  which
> >compression would be required.  If voice packets tend to be very small, then
> >compression might well be significant, even on higher speed lines.  However,
> >that does not seem to me to be a good application of a "one hop" compression
> >scheme.  It seems much better suited to a scheme which compresses at the LSP
> >ingress and decompresses  at the LSP egress, such as  is described in draft-
> >swallow-mpls-simple-hdr-compress.txt.
> >
> >So we're back to the case of low speed access lines carrying MPLS traffic in
> >a non-voice application,  and I still haven't seen a  clear statement of the
> >need.  You do hint at one:
> >
> >Lou> Think MPLS based access links that support VPNs, as one example.
> >
> >I'm not  aware of a  VPN scheme which  requires running MPLS over  low speed
> >access links.   But let  me see  if I can  guess what  you might  be talking
> >about.
> >
> >One could  imagine a piece of  Customer Premises Equipment  (CPE), a router,
> >which has  an ethernet interface  (to connect to  endusers) and a  low speed
> >wireless interface  (to connect  to the backbone).   One could  also imagine
> >that  when the  CPE  receives an  ethernet packet,  it  assign it  to a  VPN> 
> >according to some  criteria.  One could also imagine  that the CPE maintains
> >an LSP  for each VPN, with  the next LSP  hop being another router  which is
> >reached over the wireless interface.
> >
> >If this  is the  sort of thing  you're talking  about, then I  do see  how a
> >"single hop" header compression scheme could be useful.
> >
> >Of course, you could  say what you're talking about and save  the rest of us
> >the trouble of having to surmise it ;-)
> >
> >I have a little more trouble imagining why a packet on this link would carry
> >more than one label.  But  perhaps the usefulness of the compression doesn't
> >depend on there being more than one label.
> >
> >Whether this is  actually a good solution to the problem  of a multi-VPN CPE
> >connected by a slow link to  the backbone is something on which I'll reserve
> >judgment.
> >
> >Of course, if I haven't guessed  correctly the application you have in mind,
> >then I still don't see the use of the compression.

---

From: Lou Berger <[email-masked]>
Date: Mon, 24 Jul 2000 09:55:51 -0400

Thomas,
         Thanks for pointing this out, I hadn't noticed it.  As you say in 
your message, this proposal brings in more of the tradeoffs considered in 
the -simple draft.  Some of us had talked about this approach.  I think the 
simple draft captures some of the rational behind not following the 
approach you propose.

    Sophisticated header compression techniques rely on feedback to
    achieve resynchronization.  When packets are lost, the compressor and
    decompressor must resynchronize.  For an application such as voice
    over IP in the wide-area, the time necessary to achieve such
    resynchronization may be longer than the voice application can
    tolerate.

    Another consideration is the bandwidth verses processing trade-off.
    In many prospective environments it may be desirable to trade a small
    amount of compression efficiency for a less processing intense (and
    thus more scalable) compression technique.  For example, a voice
    gateway may be called upon to compress and decompress many flows.

    We propose a simple header compression technique which requires no
    resynchronization and a relatively light per packet processing load.

More generally, given that IP header compression has been found to be 
useful both in the one-hop cases and now in the multi-hop case, I think we 
should be open to both approaches for MPLS.  There are many different ways 
that, and places where, folks are envisioning using compression.

In terms of consensus I think we have:

(a) that one-hop and multi-hop compression are things that the WG should 
address (from Adelaide.)

(b) that some would like to see an approach that maximizes compression 
(from Adelaide and list.)

(c) That some would like to see an approach that operates 
multi-hop/end-to-end and is more scalable (from Adelaide and list.)

(d) (Lou's interpretation of list comments) That the proposed one-hop 
solution is acceptable as long as its usage is well constrained.
(My proposal is "recommended for use on links where IP Header Compression 
[RFC2507, 2508] is, or can be used" or "not recommend for use on links 
where IP Header Compression [RFC2507, 2508] could not or would not be used" 
depending on if the groups wants it in the positive or negative form.)

I don't think we've made much headway, beyond Adelaide on the multi-hop 
approach.

At this point, I think some in-session time would be useful in gauging 
consensus.

Vijay, George,

Oh WG chairs, is there a chance of getting some time?

If you think we're close / have some consensus (and don't need to discuss 
this next week), could you tell us what it is!

Thanks,
Lou

At 02:50 PM 7/24/00 +0200, Theimer Thomas wrote:
>Lou,
>
>I just wanted to point out that there is another proposal on the table for 
>end-end compression with MPLS that doesn't even require any changes to 
>existing header compression mechanisms. All that is needed is carrying PPP 
>over MPLS. You can then run any header compression offered by PPP end-end 
>over MPLS (be it RFC 2508/2509 or robust HC or any other scheme). You can 
>even run header compression over non-PPP links (e.g. Ethernet) if they can 
>support MPLS.
>
>The proposal is described in draft-theimer-tcrtp-mpls-00.txt. Its 
>efficiency is much better than the "simple" end-end compression, but it is 
>of course much more complex to process. However, since the compression is 
>done very close to the source, this may still be acceptable (anyway, if 
>the source is connected to the bottleneck link, it makes no difference if 
>compression is one-hop or end-end). One might even link the state of VoIP 
>calls to the compression context if desired. Eric's issue with not knowing 
>higher layer protocols is also a non-issue with end-end compression.
>
>My interpretation of this "consensus" thread is that there is more support 
>for end-end compression than there is for one-hop compression with MPLS. 
>Please correct me if I'm way off here.
>
>Thomas