Generic question about an IP tunnel - TCP-IP

This is a discussion on Generic question about an IP tunnel - TCP-IP ; Bonsoir, We know that IP is generally used in a connectionless network. That is to say that IP packets can arrive not in the same order than they are transmit. Is it the same thing when we have, in the ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Generic question about an IP tunnel

  1. Generic question about an IP tunnel

    Bonsoir,

    We know that IP is generally used in a connectionless network. That is
    to say that IP packets can arrive not in the same order than they are
    transmit.

    Is it the same thing when we have, in the WAN network, an IP tunnel,
    with the IP source address as the "tunnel head" and the IP destination
    address as the "tunnel tail".

    In other words, is it possible to guarantee that the packets put into
    the tunnel head are in the same order out of the tunnel tail (of
    course without looking TCP).

    I think to this with MPLS over IP, that is described in RFC 4023 and,
    e.g., an IP network between 2 adjacent LSR.

    Thanks for your advice,
    best regards,
    Michelot

  2. Re: Generic question about an IP tunnel

    In article
    <331490a1-7a06-40de-bc87-1d40190f64ab@m45g2000hsb.googlegroups.com>,
    Michelot wrote:

    > In other words, is it possible to guarantee that the packets put into
    > the tunnel head are in the same order out of the tunnel tail (of
    > course without looking TCP).


    In order to do this, the tunneling protocol would have to duplicate the
    ordering feature of TCP. In which case, one might wonder: why doesn't
    it just use TCP?

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: Generic question about an IP tunnel

    In article ,
    Barry Margolin wrote:

    >> In other words, is it possible to guarantee that the packets put into
    >> the tunnel head are in the same order out of the tunnel tail (of
    >> course without looking TCP).

    >
    >In order to do this, the tunneling protocol would have to duplicate the
    >ordering feature of TCP. In which case, one might wonder: why doesn't
    >it just use TCP?


    Guaranteeing packet order is a lot easier than guaranteeing data delivery.
    If your tunnel only needs to guarantee order, it need only add packet
    sequence numbers at the tunnel head and check and remove sequence numbers
    at the tail. Siliently discard packets with sequence numbers smaller
    than the previous valid packet. The only state you need to save is the
    last valid sequence number. (You might also want a very slow timer to
    clear the last valid sequence number after the tunnel has been idle for
    a long time.)

    That needs no timers, queues for retransmission, congestion avoidance,
    fast retransmission mechanisms, acks, or any of the rest of the serious
    TCP machinery. It also doesn't stall the delivery of received data for
    retransmissions, which is what you want in some applications.

    I think that description is not far from how one might implement
    the PPP MP (multilink protocol). It needs ordered frames for packet
    reassembly.


    Vernon Schryver vjs@rhyolite.com

  4. Re: Generic question about an IP tunnel

    Bonjour Barry and Vernon,

    > [from Vernon] Guaranteeing packet order is a lot easier than guaranteeingdata delivery.


    Thanks for that good differentiation. We don't have to confuse the
    both services.

    >> In other words, is it possible to guarantee that the packets put into
    >> the tunnel head are in the same order out of the tunnel tail (of
    >> course without looking TCP).

    >
    > [from Barry] In order to do this, the tunneling protocol would have to duplicate the
    > ordering feature of TCP. *In which case, one might wonder: why doesn't
    > it just use TCP?


    To avoid the "TCP machinery" (as noted by Vernon) in the MPLS over IP,
    a solution is to use a sequence number in the header of MPLS. This is
    light compared to TCP, and just that satisfies the need to guarantee
    order.

    This sequence number is described in the ITU-T recommandation Y.1415,
    section 8.3.3, for MPLS over MAC: "The Sequence number field is used
    to check the sequence integrity of MPLS packets sent from the ingress
    IWF to the egress IWF. When Ethernet services are transported over an
    underlying MPLS based network, it is required that the MPLS network
    maintain the sequence integrity of the Ethernet frames encapsulated in
    the MPLS packets".

    I think that this principle could also be used for MPLS over IP.

    > [from Vernon] If your tunnel only needs to guarantee order, it need only add packet
    > sequence numbers at the tunnel head and check and remove sequence numbers
    > at the tail. *


    Thanks for reminding me that and having me look Y.1415. Since around
    2006, this principle seems to be generalized, and called CII (Common
    Interworking Indicators).

    > [from Vernon] I think that description is not far from how one might implement
    > the PPP MP (multilink protocol). *It needs ordered frames for packet
    > reassembly.


    I think there is no possibility to put a sequence number in PPP. And
    now, the question is: how PPP can be considered as a connection
    oriented protocol?

    Brr! we have to return to school.

    Best regards,
    Michelot

  5. Re: Generic question about an IP tunnel

    In article ,
    Michelot wrote:

    >> [from Vernon] I think that description is not far from how one might implement
    >> the PPP MP (multilink protocol). *It needs ordered frames for packet
    >> reassembly.

    >
    >I think there is no possibility to put a sequence number in PPP.


    Consider the "sequence number" in the MP header in Figure 2 on page 8
    of RFC 1990, perhaps at http://www.ietf.org/rfc/rfc1990.txt

    +---------------+---------------+
    PPP Header: | Address 0xff | Control 0x03 |
    +---------------+---------------+
    | PID(H) 0x00 | PID(L) 0x3d |
    +-+-+-+-+-+-+-+-+---------------+
    MP Header: |B|E|0|0|0|0|0|0|sequence number|
    +-+-+-+-+-+-+-+-+---------------+
    | sequence number (L) |
    +---------------+---------------+
    | fragment data |
    | . |
    | . |
    | . |
    +---------------+---------------+
    PPP FCS: | FCS |
    +---------------+---------------+


    Vernon Schryver vjs@rhyolite.com

  6. Re: Generic question about an IP tunnel

    Bonjour Vernon,

    Thanks very much for that information, I'm more clever now.

    So, PPP + e.g. a sequence number = PPP MP

    I also realize one thing (and probably I forgot it).

    The main characteristic of a protocol oriented connection CO, from
    packet switching type PS, is not the guarantee of the transmit order,
    but the establishment, the maintain and the release of the connection
    (in nodes).

    As ATM, PPP is CO-PS and, usually, there is no sequence number.

    A tunnel is also like this : the main characteristic of a tunnel is
    not the guarantee of the transmit order. An IP tunnel is CL-PS
    (connectionless).

    Thanks for your agreement,
    Best regards,
    Michelot

  7. Re: Generic question about an IP tunnel

    Hello,

    Vernon Schryver a écrit :
    >
    > Guaranteeing packet order is a lot easier than guaranteeing data delivery.
    > If your tunnel only needs to guarantee order, it need only add packet
    > sequence numbers at the tunnel head and check and remove sequence numbers
    > at the tail. Siliently discard packets with sequence numbers smaller
    > than the previous valid packet.


    It this a realistic approach ?
    I mean, doesn't it cause unacceptable packet loss rates on networks
    subject to important reordering, i.e. with multipath routing or channel
    bonding ?

  8. Re: Generic question about an IP tunnel

    Bonjour Pascal,

    > > Guaranteeing packet order is a lot easier than guaranteeing data delivery.
    > > If your tunnel only needs to guarantee order, it need only add packet
    > > sequence numbers at the tunnel head and check and remove sequence numbers
    > > at the tail. *Siliently discard packets with sequence numbers smaller
    > > than the previous valid packet.

    >
    > It this a realistic approach ?
    > I mean, doesn't it cause unacceptable packet loss rates on networks
    > subject to important reordering, i.e. with multipath routing or channel
    > bonding ?


    I can give my opinion only in the WAN environment, for transport
    networks.

    In the WAN environment, when an IP packet or an Ethernet packet takes
    a path, the probability is very weak that the following packet, with
    the same destination, takes another path.

    A sequence number can be added for the network layers that are
    oriented packet-connection CO-PS. The sequence number mechanism is not
    so complex than TCP mechanism, with timers, large queues, windowing...

    My example was an interconnection of 2 MPLS LSR through an all-IP
    provider.

    In fact, it is not to the transport networks to say if the packet loss
    is unacceptable or not. If the terminal application is a real-time
    video streaming, the packet loss is not a terrible problem.

    And, if the QoS is very strict, in my example, the interconnection of
    the MPLS LSR would be through CO-CS (SDH / OTN) or other CO-PS (ATM,
    specific pt-to-pt Ethernet) paths.

    Best regards,
    Michelot




+ Reply to Thread