Re: [Detnet] IPv6 encapsulation in dataplane doc

["Pascal Thubert (pthubert)" <[e-mail]>]

I fully agree, Jouni ;

For your first point: In the case of wireless, PRP (a form of PREF) is a critical feature for industrial deployments; this is shipping and deployed today. The link that needs protection the most is the first hop (the UNI from/to the device) since it is over Wi-Fi. If the PREF starts at the network edge (say the controller), then most of the benefit is lost. So DetNet must enable E2E Services, in particular over IPv4 which is dominant in industrial use cases. What DetNet could bring to the art could that a single wireless transmission received by 2 APs end up on 2 parallel end-to-end paths.

For your second point: there are a number of potential issues if the sequencing is not done by the source end point. If a packet is received at one edge and not at another, then the sequences will differ over the 2 paths and reconciliation will be impossible. Packets received out of order at the ingress will be delivered out of order at the egress meaning that whatever support for in-order-delivery (IOD) is defeated.

My conclusion is that the end points must contribute to the effort. They must stream the data at a reasonable pace, and if Service Layer functions are expected from the network,  they really should indicate the flow ID and the sequence number from their perspective.

Now what can we expect from current end points?


-         Existing industrial devices can claim a rough need for a given rate but were not necessarily designed to provide guarantees for burstiness in DetNet terms. Failure to comply to DetNet terms may cause loss/reclassification by ingress filtering in the edge router, which would defeat one purpose of DetNet for reliability. For a close-to-acceptable sources, one can imagine a jitter absorption feature at the DetNet ingress edge router. But that also mean an additional latency, which may defeat another purpose of DetNet of in-time-delivery.

-         TCP is adverse to DetNet, and will not maintain the optimal rate; in any case, the sense of sequence that can be inferred from the offset can be defeated by retries.  In order to support TCP endpoints, one would probably need to devise a L4-proxy function (ala DLSW) that terminates TCP at the ingress edge and maps it into something more DetNet friendly.

-         UDP does not provide sequencing information - this is probably the use case for the DetNet Destination Option in the inner header.

-         Arguably RTP can signal both flow and sequence, but does not have network coding, does not expect multipath, and I'm not sure if the rate control work has gone beyond the research papers. Then again, packets may be lost or reclassified at the ingress edge.

-         This leaves rate control (e.g. adaptive bitrate streaming) to the application layer (typically over HTTP), meaning that each application as to cover for the network deficiencies in its own ways. Which is sad because it adds complexity to each and every application, a complexity that is not the core business of the app and could be handled in common at a lower layer.


DetNet has the power to simplify the application, remove jitter recovery buffers and the like, by transporting the near-perfect rate in near-perfect time.  It would be better that the end points contribution happens without impacting each and every time sensitive application, by providing DetNet Service Layer functionality at the L4 transport.
Flow identification (by port), IOD and duplicate elimination are classical L4-transport features (e.g. TCP). MP-TCP already distributes packets over different paths. It is not a gigantic conceptual step to place DetNet Service Layer features in a L4 transport. If a DetNet friendly transport -to be designed- adds DetNet Service Layer capabilities like PREF and/or network coding in the end points, 2 parallel DetNet Transport Layer circuits based on the discussion at the interim would enable the end-to-end service without knowing it. So 'd say that the proposal is still useful, but depends on L4 transport capabilities that would be fully transparent to the DetNet signaling and would not use the Destination Option.

Alternatively, say we want DetNet to provide the S-level functions, e.g. PREF. Considering that we expect that an edge router can read the ports, then it can figure what the L4 transport can be recognized and that for some transports, e.g. RTP and the suggested new transport, the edge router can derive a sequence from the transport header in a non-ambiguous way.

All the best,

Pascal

From: Jouni [mailto:[e-mail]]
Sent: jeudi 8 février 2018 10:08
To: 'Lou Berger' <[e-mail]>; Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
Subject: RE: [Detnet] IPv6 encapsulation in dataplane doc

Hi,

Yes, we discussed this to an extent in the last call. I've been thinking this a bit more lately (cross country skiing conditions have been great thus you got a lot of time while on the skiing tracks ;) Few concerns/points to think I see here are:
* End systems cannot participate to DetNet service layer packet elimination & duplication business. If they still do e.g. using DetNet DstOpt that is separate from subnet/transport layer provided service.
* Different subnet/transport layer segments in the DetNet domain are likely to use their own sequencing and duplication & elimination solutions. I am not sure how independent those will be e.g., is the sequence numbering unified across or only per segment. The former is not IMO easy and the latter easily reduces to single points between segments to handle number book keeping properly.

Regardless the above I am keen to explore this alternative approach..


-         Jouni


From: detnet [mailto:[e-mail]] On Behalf Of Lou Berger
Sent: Wednesday, February 7, 2018 17:00 PM
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc


Pascal/all,

At the last interim a proposal was made to simplify IP processing, at least for the initial detnet solution, by leaving PREF to the subnet/transport layers (i.e., TSN and MPLS) and providing DetNet flow identification based on typical IP 5-tuple perhaps + dscp. This approach has several benefits beyond simplification, notably it will work for both ipv4 and IPv6, and doesn't require any modification to encapsulation / formats.

It would be really valuable to get feedback from the whole working group if this simplification is acceptable or has unacceptable limitations.

Lou

On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" <[e-mail]<mailto:[e-mail]>> wrote:
Dear all

This is about the IPv6 encapsulation and more precisely


                        Therefore, if a DetNet-aware end system only

   inserted the DetNet Destination Option into the IPv6 but e.g., a

   DetNet Edge node is configured to enforce an explicit route for the

   IPv6 packet using a source routing header, then it has no other

   possibility than add an outer tunneling IPv6 header with required

   extension headers in it.  The processing of IPv6 packets in a DetNet

   Edge node is discussed further in Section 6.4.1<https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-01#section-6.4.1>.


With the current spec, a source sends a DetNet packet as

                    +---------------------------------+
                    |                                 |
                    |           DetNet Flow           |
                    |             Payload             |
                    |                                 |
                    /---------------------------------\
                    H   Optional DetNet DstOpt Hdr    H
                    \---------------------------------/
                    |          IPv6 header            |
                    |     (with set Flow label)       |
                    +---------------------------------+

And then the ingress node needs to re-encapsulate as



                    +---------------------------------+

                    |                                 |

                    |           DetNet Flow           |

                    |             Payload             |

                    |                                 |

                    /---------------------------------\

                    H        DetNet DstOpt Hdr        H
                    \---------------------------------/
                    |          IPv6 header            |
                    |     (with set Flow label)       |
                    +=================================+

                    |          Routing header         |

                    /---------------------------------\

                    H        DetNet DstOpt Hdr        H

                    \---------------------------------/

                    |          IPv6 header            |

                    |     (with set Flow label)       |

                    +---------------------------------+

This creates a duplication of the DetNet Destination Option.

There are alternatives


a)  whereby the packet is tunneled from the source to the detnet ingress, and based on its state the DetNet ingress accepts the packet, processes it and then resends it. The tunneled version of this could be:

                    +---------------------------------+
                    |                                 |
                    |           DetNet Flow           |
                    |             Payload             |
                    |                                 |
                    +---------------------------------+
                    |          IPv6 header            |
                    |   (dest = final destination)    |
                    /=================================\
                    H   Optional DetNet DstOpt Hdr    H
                    \---------------------------------/
                    |          IPv6 header            |
                    |   (dest = DetNet ingress edge)  |
                    |     (with set Flow label)       |
                    +---------------------------------+

Which allows the ingress to tunnel to the egress as follows:
                    +---------------------------------+
                    |                                 |
                    |           DetNet Flow           |
                    |             Payload             |
                    |                                 |
                    +---------------------------------+
                    |          IPv6 header            |
                    |      (to final destination)     |
                    +=================================+

                    |          Routing header         |

                    /---------------------------------\
                    H   Optional DetNet DstOpt Hdr    H
                    \---------------------------------/
                    |          IPv6 header            |
                    |   (dest = DetNet egress edge)   |
                    |     (with set Flow label)       |
                    +---------------------------------+



b)  whereby the PREF is done by the end nodes and the tunnel is transport only, meaning that there are 2 tunnels A and B and that the source sends twice a packet like this:

                    +---------------------------------+
                    |                                 |
                    |           DetNet Flow           |
                    |             Payload             |
                    |                                 |
                    /---------------------------------\
                    H   Optional DetNet DstOpt Hdr    H
                    \---------------------------------/
                    |          IPv6 header            |
                    |   (dest = DetNet ingress edge X)|
                    |     (with set Flow label)       |
                    +---------------------------------+

And then the ingress node needs to re-encapsulate as



                    +---------------------------------+

                    |                                 |

                    |           DetNet Flow           |

                    |             Payload             |

                    |                                 |

                    /---------------------------------\

                    H        DetNet DstOpt Hdr        H
                    \---------------------------------/
                    |          IPv6 header            |
                    |   (dest = final destination)    |
                    |     (with set Flow label)       |
                    +=================================+

                    |          Routing header         |

                    +---------------------------------+

                    |          IPv6 header            |

                    |   (dest = DetNet egress edge X) |

                    |     (with set Flow label)       |

                    +---------------------------------+

Cheers,

Pascal
_______________________________________________
detnet mailing list
[e-mail]<mailto:detnet%40ietf.org>
https://www.ietf.org/mailman/listinfo/detnet