Hi, On 2013-11-21, at 11:56, Jose Saldana <[email protected]> wrote: > - in a pair of appliances creating a tunnel between two offices of a > company, there are a number of hops. Interesting for TCM-TF
there are multiple hops, but are there pressing resource constraints? The intranet in all companies I have worked for has worked well enough without TCM-TF. If you lease MPLS circuits, you can easily acquire more bandwidth. > But what happens if a scenario may involve one, two or more L3 hops? This > will happen in a "community network": you can create a tunnel just to > connect a village with the Internet (one hop), or to connect a village with > another village, which is the one really connected to the Internet (more > than one hop). See a paper about the topology of these networks here > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6379103. All of these PEPs really only make sense on the resource-constrained hop. In your village example, put them on each side of the congested link. Then it's a one-hop scenario. There is little point in going through the overheads of compressing, tunneling, etc. when there is ample resource capacity. > Perhaps we should take this into account when thinking about the "TCM-TF > negotiation". Suppose there are two TCM-optimizers that want to create an > optimized tunnel. During the negotiation they SHOULD check if the number of > L3 hops between them is 1. In that case, they can avoid the tunnel, and also > the multiplexing (and multiplexing delay in turn). This could be seen as a > particular case of TCM-TF: > > - Compression layer: ROHC > - Multiplexing layer: send every single packet. No need for PPPMux > - Tunneling layer: no tunnel > > So perhaps we should also consider the "no multiplexing" and "no tunneling" > options in the protocol stack, in order to cover these cases. The point I'm trying to make is that I haven't seen *any* scenario that requires a multi-hop solution. And therefore to me what we have with ROHC seems to be just fine. Lars
signature.asc
Description: Message signed with OpenPGP using GPGMail
