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

From: Eric Gray <[email-masked]>
Date: Fri, 21 Jul 2000 18:48:22 -0700

Lou,

	Sorry it took me so long to get back to you.
Please see below.

> [...]
> >
> >         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.
> 
> 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.

Semantics.  If you are talking about a single link
compression, then you are already assuming you know
for certain that the header following the bottom of
stack label is an IP header - like this

   ----------- ------------ ----------- -------------
  | L2 Header | MPLS Stack | IP Header | Packet Data |
   ----------- ------------ ----------- -------------

So, you know you can cut it like this

   -----------  |  ------------  |  -----------  |  -------------
  | L2 Header | | | MPLS Stack | | | IP Header | | | Packet Data |
   -----------  |  ------------  |  -----------  |  -------------

Then you can apply the same compression techniques to 
the IP header and change the discriminator value in 
the L2 Header to get

   ------------  |  ------------  |  ------  |  -------------
  | L2 Header' | | | MPLS Stack | | | IPH' | | | Packet Data |
   ------------  |  ------------  |  ------  |  -------------

where L2 Header-prime includes a discriminator for
compressed IP header in MPLS and IPH-prime is the
compressed IP header.  Glomming it back together
gets you this

   ------------ ------------ ------ -------------
  | L2 Header' | MPLS Stack | IPH' | Packet Data |
   ------------ ------------ ------ -------------

Certainly the existing compression technique works.

> 
> >         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).
> 
> I can't figure out what "precedent" you are referring to. 
>

That's okay.

> 
> The traffic is standard IP not compressed IP.

Yes.  And your point is?  Surely you are NOT going
to give me a hard time for omitting a word...

> 
> [...]
> 
> > Also, it is possible to choose an approach that 
> > makes this statement invalid.
> 
> Again, the earlier statement is one of fact not opinion.

I think I have shown that this "fact" is not true.
I have described an approach that shows that the
existing compression technique will operate.  You
have to do a tiny bit more work, but you have to
do that much in your scheme as well.

> 
> [...]
> 
> > 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.
> 
> A minor note, a replacement for rfc2509 would need 
> to be written to enable this.

Actually, one of your drafts could - with very minor
modification - perform this 'replacement' task.  It
could also serve to describe the simplistic approach
to using already defined IP header compression over
uncompressed MPLS shim header.  Or, it could be merged
with the -simple draft.

> 
> >         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.
> 
> I don't think you mean intermediate LSR here, next hop or 
> downstream is accurate.  (remember such compression is 
> hop-by-hop.)

I'm thinking in generalities.  Suppose a 'low speed'
link of the future is an LSP.  Where do you go with
this approach then?  Answer, you probably don't.  I
like to think it's a good idea to think "no future,
no present" when it comes to developing standards.

> 
> 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.

If you assume that there is one MPLS label in the shim header,
then the difference is simply 4 bytes.  The actual size of the
compressed IP header is not 2 or 4 bytes, but (according to RFC
2507) actually 4-7 bytes.  I assume that all the same extra
values have to be carried when the MPLS header and the IP header
are compressed together (although I might have to add a nibble,
at least, for the EXT field), so the delta should be more like
8-15 bytes verses 4-8 bytes.  This delta is not so stark as the
2-4 verses 6-8 - at least when expressed as a percentage.

If you assume more than one MPLS label, then the delta becomes
more pronounced.  But how likely is this?

> 
> [...]
> 
> >         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.
> 
> I don't everyone would agree with this statement.

But, apparently, the question does come up. :-)

> [...]
> Thank you,
> Lou
> [...]

Have a nice weekend!

--

---

From: Lou Berger <[email-masked]>
Date: Sun, 23 Jul 2000 08:58:46 -0400

Eric,
         I'm not sure where we are right now in the discussion.

One issue is consensus:

I think we have or are close to having general consensus, at least on the 
list, that "one hop" (using Eric R's terminology) compression has it's 
place, albeit a very narrow one.

Another issue is specific approach:

In the "one-hop" case maximizing efficiency is paramount so the inclusion 
of one or more MPLS in the compressed header is appropriate.

I'll also responded to your specific points below, although I'm less sure 
there's general interest in the details.

Lou

At 06:48 PM 7/21/00 -0700, Eric Gray wrote:
>Semantics.

I disagree.  There current RFCs just don't work when MPLS is used, they 
only cover the case where the IP header follows the link layer (PPP in the 
RFC2209 case).  There is no argument.  Yes, there are different ways to 
adapt the specs to work when there is an MPLS label stack present.  As you 
pointed out in an earlier mail, we even mentioned this in the draft.

>  If you are talking about a single link

Right, again we briefly referenced this possibility in the draft.  As the 
draft says:
    Other methods for supporting IP and IP/UDP/RTP header compression
    over MPLS are possible and some where considered.  One alternative
    worth noting is adapting the existing header compression techniques
    to operate directly over MPLS without any MPLS header compression.
[...]  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.

>to give me a hard time for omitting a word...

Your point appeared to be based on the premise that "compressed IP" was 
being transported.  I accept that this was a typo.  Point dropped.

>do that much in your scheme as well.
Here's the text in question:

    1. Introduction

    IP and IP/UDP/RTP header compression, which is defined in [RFC2507]
    and [RFC2508], reduces header overhead and is particularly useful on
    lower speed links.  The current header compression definition relies
    on IP datagrams being carried directly over a link layer protocol,
    such as PPP [STD51].  With the introduction of MPLS [LABELS], one or
    more MPLS headers, which are called label stack entries, may be
    present between the IP and link layer headers.  Since the header
    following the link layer header is no longer IP, the existing
    compression techniques will not operate.

The "existing compression techniques" as specified in published RFCs won't 
work.  Period.  Yes 2508 and 2507 can be applied without modification, but 
2509 cannot.  I included all three in "existing compression techniques" as 
they are commonly used together.  Is your point simply that I should have 
added "RFC2509 in particular"  to the last sentence?  If so, sure point 
taken and we can add that clause.

>modification - perform this 'replacement' task.

Ahh, violent agreement.

>  It

They're two disjoint compression schemes.  Why have a spec that covers two 
topics, each of which may be independently implemented.

>no present" when it comes to developing standards.

Again, as long as this "low-speed" link transport mechanism can support IP 
and IP header compression, there won't be an issue.

>then the difference is simply 4 bytes.

Right, but I think this is too limiting an assumption.

>The actual size of the
>2507) actually 4-7 bytes.

it's:
         2 bytes for MPLS/IP/UDP/RTP when UDP checksums aren't used
         4 bytes for MPLS/IP/UDP/RTP when UDP checksums are used
         I believe it's 7 for MPLS/IP/TCP but would need to check.

>I assume that all the same extra
>at least, for the EXT field),

This is already covered in the draft.

>  so the delta should be more like

I believe the numbers I stated are correct.  Certainly there are mixes of 
traffic that result in MPLS/IP or just IP header compression being less (or 
even not) useful.

>more pronounced.  But how likely is this?

Some envision two or more labels as the norm.  (as discussed in another 
thread.)

>But, apparently, the question does come up. :-)

agreed.

Lou

---

From: Grenville Armitage <[email-masked]>
Date: Sun, 23 Jul 2000 11:44:46 -0700

Lou Berger wrote:
	[..]
> there's general interest in the details.

Details speak to the question of whether your draft (as totally new
work) is preferable to developing a diff to some existing compression
approaches. Please do post your evaluations to the list, even if only
for archival purposes.

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: Lou Berger <[email-masked]>
Date: Sun, 23 Jul 2000 14:52:43 -0400

Grenville,

The draft *is* a diff/extension to the existing IP (rfc2507) and IP/UDP/RTP 
(rfc2508) header compression schemes. And draft-ietf-mpls-hdr-comp-over-ppp 
is a minor diff/extension to rfc2509.

Lou

PS The "-simple" approach is a totally new one.  This is appropriate as 
draft-ietf-mpls-hdr-comp- and the 2507/8 are "one-hop" based, while 
"-simple" is multi-hop.