The MPLS WG Archive

[Theimer Thomas <Thomas.Theimer@icn.siemens.de>]

Lou,

I agree that there are some tradeoffs to be made regarding complexity and bandwidth efficiency. My take on this is:

- if you can do header compression for the link connected to a voice gateway, complexity is the same for one-hop or end-end compression, if you use the same compression technique. So you can also do end-end compression without adding more complexity.

- as you said, packet loss is a problem for current RTP header compression. My assumption was that the LSP carrying voice can be constrained such that packet loss is virtually eliminated, so the problem does not occur. Isn't that one of the reasons for putting voice onto MPLS in the first place ? Assuming that packet loss is sufficiently rare, a larger round trip delay (read: more RTP packets lost due to context mismatch) should not be too critical. A voice gateway could also do some intelligent things to fill the gaps when packets are lost, so the voice application may not even notice any difference.

- if packet loss cannot be eliminated, use a more robust header compression scheme to be defined by ROHC folks.

- if that still doesn't work, or you can't tolerate the complexity, use simple header compression.

I guess we can now argue if the above assumptions are reasonable or if simple header compression is the only way to make this work.

Thomas

> -----Original Message-----
> Lou Berger [SMTP:lberger@labn.net] wrote: 
> 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