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

From: Eric Gray <[email-masked]>
Date: Thu, 20 Jul 2000 12:54:20 -0700

Folks,

	My technical comments.

	I do not think the statement -

"Since the header following the link layer header 
 is no longer IP, the existing compression techniques 
 will not operate"

- which appears in the abstract of the ID entitled
"MPLS/IP Header Compression" has been given enough 
thought.  

	This statement points out that this draft may
be setting a precedent for how MPLS works when the
link layer needs to indicate that the data frame is
not IP (because it is MPLS) and the data encapsulated
is not standard IP (because - in this case - it is
compressed IP header).  Also, it is possible to choose 
an approach that makes this statement invalid.

	I do not think that the precedent this draft 
may set is a good one.  While the draft states that 
the alternative of using IP header compression - as
is - over MPLS was considered, I think this option
was too quickly dismissed.  

	One of the reasons it was dismissed was that 
MPLS headers do not carry packet type codes.  In 
making this decision in design of MPLS, we setup a
general requirement to define new type codes for 
applicable link layers WHEN IT IS IMPORTANT FOR AN
INTERMEDIATE LSR TO KNOW THE PROTOCOL OF THE DATA
PACKET ENCAPSULATED BY MPLS.  Hence, if we determine
that there is a need for intermediate LSRs to know
that the MPLS encapsulated packet uses IP header
compression, then we might be justified in defining
new link layer discriminators (packet type codes)
for such packets when transported over MPLS.

	This draft fails completely to justify a need
for intermediate LSRs to understand that MPLS packets
may encapsulate compressed IP headers.  In fact, the
possibility that there may be intermediate LSRs is 
not sufficiently explored, since this possibility 
implies the further possibility of needing to stack
additional MPLS labels (this is discussed below).

	If it is not important for intermediate LSRs
to understand that header compression is used, then 
one very good approach is to define extensions to a
signaling protocol such that each end of an LSP will
know that the LSP itself is being used to transport
IP-header-compressed data packets.  This alternative
does not appear to have been considered.  Yet this
is the alternative currently used most often to deal 
with LSP end-to-end requirements.  Such an approach
should be straight-forward and should have no impact
on LSRs that do not need to support this capability.

	A second reason for dismissing other approaches 
was that additional compression efficiency could be
obtained by compressing the MPLS shim header as well.
I do not see that the potential for compressing one
32 bit word justifies the proposal.  Further, I doubt
the existence of an application for multiple stacked
labels being transported across a low-speed link - 
thus it does not seem likely that the MPLS shim header 
will be much larger than 32 bits.

	Which is a segue into problems with intermediate
LSRs: the possible existence of intermediate LSRs means
that there might be a need to further encapsulate an
MPLS labeled packet by pushing on an additional label.
For example, the low-speed link might be carried in an
LSP trunk.  If an LSR is faced with the need of adding
a label to the stack of an MPLS-header-compressed packet,
how is this done?  Is there an impact if there is a
need to further stack labels as the packet is progressed
toward the core of a network?  

	I think there is an impact in the current proposal.  
I also feel certain there is not in either proposal I
would make (have made, if you read the above carefully).
I believe that - unless the current proposal can provide
a means to preclude its use across low-speed links that
are transported using LSP trunks - this proposal will
have far reaching implications on not-so-slow links.

	Hence, I feel this draft uses the wrong approach
at a very fundamental level and do not feel that it is
the approach that the MPLS working group should adopt.

--
Eric Gray

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Thursday, July 20, 2000 11:17 AM
> To: [email-masked]
> Subject: Consensus on compression
> 
> 
> Folks,
> 
> Since there clearly is confusion over whether consensus over adopting 
> 
> 	draft-ietf-mpls-hdr-comp-over-ppp-00.txt
> 	draft-ietf-mpls-hdr-comp-00.txt	
> 
> and since the minutes don't clearly indicate that there was, then we
> need to start again.  So, lets discuss see if we can reach consensus
> on the list.  If a consensus forms, we'll declare it prior to the
> meeting.  If not, we'll allocate a bit of time to discuss it there.
> 
> Note that this is not a package deal.  The two drafts should be
> considered independently (and on separate threads).
> 
> ...George
> 
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 
> 
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 20 Jul 2000 17:10:17 -0400

Eric,
         I guess I managed to get your attention:-)  I'll try to respond to 
your specific points in-line below.  First a couple of general comments:
- The draft in question only compresses data between two MPLS nodes.
   (Just like IP/UDP/RTP compression.)
   Multinode compression is covered in the -simple draft and is useful
   when there are different optimization requirement.
- It is intended for use on links where per packet transmission overhead is 
critical.
- It is a minor extension to RFC2207/8 and operates basically in the
   same fashion.

>"MPLS/IP Header Compression" has been given enough

I don't see how you can argue with the statement.  Current IP header 
compression [RFC2507, 2508, 2509] relies on the IP header immediately 
following the PPP header.  That's the way it's specified.  What's the argument.

>compressed IP header).

I can't figure out what "precedent" you are referring to.  The traffic is 
standard IP not compressed IP.

IP header compression is done one a link by link basis.  From the 
compressing node's perspective the data is standard IP.  The draft enables 
the compressing node to compress the MPLS/IP and other headers (to 2 or 4 
bytes).  If running MPLS, the current alternative is to send uncompressed 
MPLS/IP/UDP headers (40 bytes + 4 bytes/mpls hdr).

>Also, it is possible to choose

Again, the earlier statement is one of fact not opinion.

>may set is a good one.

Again, what precedent?

>While the draft states that

A minor note, a replacement for rfc2509 would need to be written to enable 
this.

>for such packets when transported over MPLS.

I don't think you mean intermediate LSR here, next hop or downstream is 
accurate.  (remember such compression is hop-by-hop.)

The general comment is still valid, while a bit awkward, we could use link 
layer types to indicated they type of data being carried within the MPLS 
stack.  As the document states, this issue wasn't the critical one.  From 
the same paragraph in the document:
    [...] The second and
    more important reason for not adapting compression to operate over
    MPLS was simply to gain extra efficiency by enabling the compression
    of the MPLS label stack.

The delta here is from (2 or 4 bytes + 4bytes/mpls header) versus 2 or 4 bytes.

>may encapsulate compressed IP headers.

Again, I don't get this statement.  The proposed compression is 
hop-by-hop.  The compression may be done on a per link basis.  Multinode 
compression is covered in the "-simple" scheme.  Yes, each end of the link 
need to agree on doing compression and needs to understand that it's 
compressing IP.   The justification is 44 bytes compressed to 2 or 4 
bytes.  I think the draft made this clear.

>In fact, the

Again, the discussed scheme operates on *single* links only.  A compressed 
header is never seen by a non-supporting nodes.  This is how rfc2507 and 
2508 operate.

>on LSRs that do not need to support this capability.

This alternative is described in the "-simple" scheme
(draft-swallow-mpls-simple-hdr-compress-00.txt.)  As mentioned in Adelaide 
and reflected in the minutes both schemes have their place.

>will be much larger than 32 bits.

I don't everyone would agree with this statement.

Think MPLS based access links that support VPNs, as one example.

>MPLS labeled packet by pushing on an additional label.

Again, "intermediate node" just doesn't apply to this draft.

>LSP trunk.

What does this mean?  If you mean that at least the PPP header and above is 
encapsulated, than there's no issue.  It's the same issue as handling IP 
header compression over low-speed links.  (BTW how are you planing on doing 
this?)  If you means something else, you have to define what you're talking 
about.

>If an LSR is faced with the need of adding

I don't believe these questions apply.  Per standard IP header compression 
the receiving link decompresses the received packet and then forwards a 
standard, uncompressed packet.  The compression process may be repeated on 
the outgoing interface but this is independent of how the packet was received.

>have far reaching implications on not-so-slow links.

This single issue should be addressed the same way as when low-speed links 
carrying compressed IP headers are transported using LSP trunks.

Again, I'm also not sure what "low-speed links that are transported using 
LSP trunks" means.  Will you define this?  Are you talking about some 
proprietary approach?

>the approach that the MPLS working group should adopt.

Given my comments, it seems to me that you had some fundamental 
misunderstandings
of the draft.  Furthermore your major objections is too nebulous to respond 
to in a substantive way.  (And as long as whatever solution you propose 
supports standard IP header compression, per RFCs 2507 and 2508, the 
presented approach *will* work.)

Please respond and elaborate.

Thank you,
Lou

---

From: Eric Rosen <[email-masked]>
Date: Fri, 21 Jul 2000 13:32:06 -0400

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: Fri, 21 Jul 2000 13:58:12 -0400

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

---

From: Eric Rosen <[email-masked]>
Date: Fri, 21 Jul 2000 14:10:27 -0400

Lou> The case I was thinking about is were there is an inner label that 
Lou> indicates VPN and an outer label that indicates an egress. 

What makes this  case problematic is that pushing on  these two labels would
be a  function of the Provider Edge  router, which is much  less likely than
the CPE to be separated by a low speed link from the backbone. 

If you  want your  draft to be  considered for  standards track, I  think it
should have  a much clearer statement  of its purpose,  maybe even something
like "not recommended for use on links faster than 9.6Kb", or something like
that.  And  a clear  statement that its  use is  optional.  That way  when a
potential  customer complains that  an implementation  is not  conformant to
standards  because it  doesn't use  single  hop compression  on its  gigabit
ethernet link, one can just refer the customer back to the document itself.

---

From: Bora Akyol <[email-masked]>
Date: Fri, 21 Jul 2000 11:27:43 -0700

I for one think that the one hop strategy is unacceptable especially if this
continues "one hopping" through to the core routers. If the access box
terminates the one hop compression and then sends normal MPLS packets then this
is OK; otherwise, this is a major change in the architecture and should be
avoided at all costs.

Bora

---

From: Lou Berger <[email-masked]>
Date: Fri, 21 Jul 2000 14:45:33 -0400

I have 0 issue with narrowing the scope.  I suggest some alternate wording 
below.

Lou

At 02:10 PM 7/21/00 -0400, Eric Rosen wrote:

>that.

How about "recommended for use on links where IP Header Compression 
[RFC2507, 2508] is, or can be used."

>And  a clear  statement that its  use is  optional.

100% agreed.  Again, just like IP Header Compression.

>That way  when a

---

From: Lou Berger <[email-masked]>
Date: Fri, 21 Jul 2000 14:49:26 -0400

Bora,
         It works just like standard IP header compression.  (It is after 
all, just a minor extension to it.)  "[...]the access box terminates the 
one hop compression and then sends normal MPLS packets [...]"  is what is 
documented.    Just like in normal IP header compression, a decompressor 
could compress on the outgoing link, but this isn't the norm.

Lou

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 21 Jul 2000 15:17:31 -0400

Bora Akyol writes:

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Bora
> Akyol
> is OK;

Based on my experience of implementing and using IP header compression
over slow (19.2 Kbps and 14.4 Kbps) wireless links, implementing
header compression schemes even on a single hop are a big pain as
header compression requires synchronized session states at both ends
of a link. If the sessions are short, or too many sessions are
multiplexed over multiple slow links  controlled by a single box,
processing overheads of header compressions are non-trivial.  In these
situations, operators and the devices may find better throughput by
disabling header compression all together at both ends. In short,
contrary to the popular myth, header compression is not always useful
over slow links.

Cheers,

--brijesh
Ennovate Networks Inc.

>otherwise, this is a major change in the architecture
> and should be
> avoided at all costs.
>
>