Re: [Raw] FW: How do tracks differ from TE protection paths? was: Some comments/questions on RAW Architecture

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

Hello Lou:

I'm using Quantum physics as an image. For me, a Track is to a TE path what an atomic orbital is to a planetary orbit.

The orbit is a predictable fact, and a path is observable after the fact. 

A Track cannot be observed; it only represents the aggregate of the possible places that the packet may traverse. But due to PSE activities we do not know in advance (before PSE computes it) which places a packet will attempt to traverse. And because of wireless loss, even after the PSE decision we are not sure that the packet will traverse those places. 

If the packet is split and network coded, codes will be at different places at each point of time, so the packet will effectively be in multiple states at the same time, and not necessarily precisely somewhere at a specific time. 

My concern is that if we keep overloading the term path, we are losing the capability to describe anything precisely, we forget what we talk about. A track is the aggragtion of feasible path, not a path, and it is used statistically, not definitely.

A bit more inline below 😊

All the best,

Pascal

> -----Original Message-----
> From: Lou Berger <[e-mail]>
> Sent: vendredi 23 septembre 2022 21:14
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: FW: How do tracks differ from TE protection paths? was: Some
> comments/questions on RAW Architecture
> 
> Hi Pascal,
> 
> On 9/16/2022 9:02 AM, Pascal Thubert (pthubert) wrote:
> > Dear Lou:
> >
> > I'm trying to figure out what's left to be added to the RAW
> architecture. So I'm going again through our collection of old emails.
> >
> > I went through RFC 4426 and RFC 4427 as you suggested. Consistent with
> my earlier understanding, 1+1 only does the R in PREOF, and only at the
> ingress.
> 
> GMPLS Segment Recovery, RFC4873, and Fast reroute RFC4090 are two examples
> of RE performed in the middle of the network.

Fast reroute is a path update. The orbit has changed but it is still not an orbital.


> 
> >   RFC 6372 also deals with linear (not graph) protection and P2MP is
> just a collection of that where the property of each link is essentially
> the same as above.
> >
> > Since it does not have E and O, there needs to be an active switch over
> at the egress. The consequence is that for a packet there is effectively a
> path that is selected by the receiver and that all packets will follow
> till the receiver end switches.
> I agree, that the above do not include sequence numbers to support O.
> But O is not a strict requirement at the IP layer in the general IP case
> at the network layer, as I'm sure you know.
> > RAW has PAREO active all along the Track, with dynamic decision-making
> either at egress or even deep in the graph. The graph is not a series of
> parallel oriented paths. The graph is the sum of all potential and
> overlapping paths that packets of the flow may experience, and there is no
> decision at egress on which path is selected. I guess that the first
> packet that is received for a sequence and is retained and reordered.
> 
> 1:1 and 1:n (and I think) FRR basically upstream selects on which path
> to use, only 1+1 (like PREOFF) and 1+n have downstream/receiver selects
> (of data to use).

I do not see that. The path is updated, but is still definitely something not an aggregate of statistical chances.

> 
> > OTOH the art of TEAS seems consistent with the rest of IETF literature
> that describes the path as the experience of a packet (see refs in the
> draft), whereby it is known at a each point of time which path packets of
> the flow will experience. A Track is the quantum physics of that, all
> probabilistic, and the path is only known when the packet is received.
> Please be sensitive to the difference in nature of those 2 objects.
> 
> I don't understand your comment about at the physics level.  RAW isn't
> about defining wave forms (in ITU speak, media channels) but rather
> about using such for IP.  If you're alluding to the "overhearing" that
> is possible in wireless - how is it so different than sending an IP
> packet (unicast or multicast) over a ethernet multicast and letting
> multiple receivers process/forward the packet.
> 
> > In my book that's enough difference to call it differently, and to
> differentiate the measurable path from the potential Track.
> >
> > Do I (finally) manage to make sense?
> 
> I suspect we're still talking past each other.
> 
> Thanks!
> 
> Lou
> 
> > Pascal
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: RAW <[e-mail]> On Behalf Of Pascal Thubert (pthubert)
> >> Sent: vendredi 29 juillet 2022 17:58
> >> To: Lou Berger <[e-mail]>
> >> Cc: [e-mail]
> >> Subject: Re: [Raw] FW: How do tracks differ from TE protection paths?
> was:
> >> Some comments/questions on RAW Architecture
> >>
> >> Thank you, Lou, I'll look at it, though probably not today.
> >>
> >> Compared to 1:N, a Track has replication + elimination + overhearing
> inside
> >> the graph east-west and north/south synchronization. It also enables
> >> spreading coded fragments. It can be seen as the aggregation of all the
> >> possible and partially congruent paths that you can use for a packet.
> That's
> >> not what I'm used to figure for N:1. I'd like to find words that relate
> the
> >> concepts and yet carry the difference to place in the definition.
> >>
> >> I've already been working on edition to indicate that the controller
> plane is
> >> not necessarily centralized, and that the PAREO function may be
> controlled
> >> from the detnet service layer but actuated in the lower layers, which
> is the
> >> case of other things already. I hope I can push the github for the
> proposed
> >> diff for at least this before I disappear for 2 weeks.
> >>
> >>
> >>
> >> Enjoy summer!
> >>
> >> Pascal
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Lou Berger <[e-mail]>
> >>> Sent: vendredi 29 juillet 2022 17:37
> >>> To: Pascal Thubert (pthubert) <[e-mail]>
> >>> Cc: [e-mail]
> >>> Subject: Re: FW: How do tracks differ from TE protection paths? was:
> >>> Some comments/questions on RAW Architecture
> >>>
> >>> Hi Pascal,
> >>>
> >>> On 7/29/2022 9:19 AM, Pascal Thubert (pthubert) wrote:
> >>>> Dear RAWers:
> >>>>
> >>>> Resending with additions:
> >>>>
> >>>> -----Original Message-----
> >>>> From: Pascal Thubert (pthubert)
> >>>> Sent: vendredi 22 avril 2022 17:09
> >>>>
> >>>> Lou said:
> >>>> "
> >>>>> In reading the definition of the tracks, the term seems quite
> >>> aligned/similar to TE protection paths and segments.
> >>>>> Keep in mind that DetNet PREOF is just one form of service
> >>>>> restoration
> >>> supported in IETF TE, i.e., the 1+1 form.
> >>>>> A track reads to me to be something that can be composed or combine
> >>>>> 1:1,
> >>> 1:N and even 1+N, and have interesting (uncoordinated) protection
> >>> switching based on actual network/link (channel) state.  I suspect we
> >>> can accomplish the same objectives as Tracks and stay consistent with
> >>> existing DetNet and
> >>> TE(AS) terminology.
> >>>> "
> >>>>
> >>>> My short answer:
> >>>> There's too much preconception with the term path as an experience
> >>>> and
> >>> too much slight overload of the term path in different WGs, sometimes
> >>> without a clear terminology but rather an intuition that means
> confusion.
> >>> We need a term that reflects the statistical expectation and
> >>> overloading path will entertain / augment the existing confusion.
> >>> Defining Track allows us to point explicitly on what happens at DetNet
> >>> and RAW that is really new.
> >>>> The difference between a path and a Track is subtle. A path is an
> >>> experience, a Track is a collection of potential experiences. Worse: a
> >>> Track may be flooded with network coded fragments of the datagram, so
> >>> there's no such a thing as the path that the datagram followed. Still
> >>> I see the need to position Track and Protection Path (which in most
> >>> findings in google reads as path B when path A fails). Could you
> >>> please provide a pointer to the TE terminology?
> >>> I really think this work can be informed by the prior protection work
> >>> done for TE in the IETF.  I wish it was nicely summarized in
> >>> draft-ietf-teas- rfc3272bis-20, but it isn't.  Probably the best
> >>> references are: rfc4426, rfc4427, and rfc6372.
> >>>
> >>> I think what you are describing with tracks and PSEs are 1:N span
> >>> protection with Unidirectional (recovery) switching over DetNet member
> >>> flows (which use paths).
> >>>
> >>> Can you take a look at the references and see what you think?
> >>>
> >>> Thanks,
> >>>
> >>> Lou
> >>>
> >>>> Longer answer:
> >>>>
> >>>> My view is that the concept of path in the art of IETF is
> >>>> incompatible
> >>> with that of Track because a path has the classical IP expectation of
> >>> 1 packet in, the same packet along, and then out. In TE, even in the
> >>> 1+N case, the packet is replicated first, and then each copy follows a
> >>> path where the assumption above stands. A  copy is an atom that
> >>> remains in its integrity along the path. The path can thus be defined
> >>> after the fact as the experience of the (copy of the) packet. And we
> >>> can define a protection path as a set of such paths for multiple
> >>> copies, either sent at the same time or deferred.
> >>>> I believe that in RAW, and even in DetNet, the capability to
> >>>> replicate
> >>> inside the network already defeats that definition. When a packet is
> >>> replicated inside the network, which one is the original that follows
> >>> the path? What is the path for the copy? If a relay fragments a packet
> >>> into N frags, uses network coding N->P, P>N between the fragments as
> >>> redundancy technique, and then distributes the fragments across the
> >>> feasible next- segments within the Track, the packet is not more an
> >>> atom, and there's no "path" that the packet experiences. The packet is
> >>> literally disseminated (as opposed to flooded as an atom) and
> reconstituted
> >> at arrival.
> >>>> If I'm unclear, maybe a quantic analogy will help. The path is the
> >>> observation/measurement of how an atomic packet traversed the network
> >>> (which hole the photon passed through). In the case of network coded
> >>> fragments, there are superimposed "path" states, each with its own
> >>> probability. The Track describes the superimposition, not the
> measurement.
> >>> It is expressed as the set of statistical possibilities for a future
> >>> packet, not the experience of one.
> >>>> Note: The sum of probabilities is typically more than 1 due to
> >>>> redundancy
> >>> methods, and the PSE dynamically DECIDEs the new values for those
> >>> statistics to place them on segments that appear to work at this time
> >>> based on ORIENTation by the PCE (D and O in OODA).
> >>>> In terms of IETF inheritance, the term Track is already defined in
> >>>> the
> >>> art of a deterministic wireless RFC (RFC 9030) and a method to program
> >>> Tracks in a wireless network is being defined at ROLL
> >>> (draft-ietf-roll-dao- projection). The definition of Track at RAW,
> >>> ROLL, and 6TiSCH are consistent, though ROLL can only build Tracks
> >>> that are DODAGs (it cannot build bidir North/South segments).
> >>>> I hope this helps,
> >>>>
> >>>> Pascal
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Lou Berger <[e-mail]>
> >>>> Sent: lundi 21 mars 2022 2:25
> >>>> To: [e-mail]
> >>>> Cc: RAW WG <[e-mail]>
> >>>> Subject: Some comments/questions on RAW Architecture
> >>>>
> >>>> Pascal, Georgios,
> >>>>
> >>>> In looking to provide input on the framework document I realized I
> >>>> had
> >>> some basic questions on the architecture document. While I also have
> >>> more detailed comments/questions on the Architecture document, I'll
> >>> stick to the high level comments/questions here. Also, my apologies
> >>> for not getting them out sooner, but I figured it was still better to
> >>> document here than just "at the mic" in tomorrow's session.
> >>>> 1) What does the term "RAW" refer to in the context of the
> architecture?
> >>>> Is it a new/standalone set of mechanisms or is it an addition or an
> >>> extension, or a usage of IETF defined technologies?
> >>>> I find that reading the architecture, I'm really  unsure.  The
> >>>> current working is a bit mixed, e.g.,
> >>>>
> >>>>       Reliable and Available Wireless (RAW) provides for high
> reliability
> >>>>       and availability for IP connectivity over a wireless medium.
> >>>>
> >>>> this sounds like something new/independent
> >>>>
> >>>>       It builds on the DetNet Architecture and
> >>>>       discusses specific challenges and technology considerations
> >>>> needed
> >>> to
> >>>>       deliver DetNet service utilizing scheduled wireless segments
> and
> >>>>       other media, e.g., frequency/time-sharing physical media
> resources
> >>>>       with stochastic traffic.
> >>>>
> >>>> this sounds evolutionary.
> >>>>
> >>>> I was expecting the RAW WG to build on DetNet and other IETF Traffic
> >>> Engineering (TE)  bodies of work. In other works something along the
> >>> lines
> >>> of:
> >>>>        The RAW Architecture builds on the DetNet Architecture and
> >>>>        standard IETF Traffic Engineering concepts and mechanisms to
> >>>>       deliver service across any combination of wired and wireless
> >>>>       network segments. ...
> >>>>
> >>>> I think the document and the used terminology must be clear even
> >>>> we're
> >>>> (understandably) loose in the usage of the "RAW" term in our
> discussions.
> >>>>
> >>>> 2) Are RAW solutions limited to IPv6 and a limited set of wireless
> >>> technologies?  I think the framework says/implies no, but the
> >>> architecture is less inclusive. e.g.,
> >>>>       RAW provides DetNet elements that are specialized for IPv6
> flows
> >>>>       [IPv6] over selected deterministic radios technologies [RAW-
> >>> TECHNOS].
> >>>> I would expect that at least at the Architecture level that there
> >>>> would
> >>> be no exclusion of IETF networking technologies (including v4 and
> >>> MPLS) and any SDO-defined wireless technology.  I certainly understand
> >>> needing to focus and prioritize work on specific technologies, but
> >>> that is practical choice not a limitation that should be codified in
> the
> >> architecture.
> >>>> Somewhat related, but of less importance, it's probably worth
> >>>> mentioning
> >>> that RAW forwards/switches at the IP, not link layer.
> >>>> 3) How do tracks differ from TE protection paths?
> >>>>
> >>>> In reading the definition of the tracks, the term seems quite
> >>>> aligned/similar to TE protection paths and segments.  Keep in mind
> >>>> that DetNet PREOF is just one form of service restoration supported
> >>>> in IETF TE, i.e., the 1+1 form.  A track reads to me to be something
> >>>> that can be composed or combine 1:1, 1:N and even 1+N, and have
> >>>> interesting
> >>>> (uncoordinated) protection switching based on actual network/link
> >>>> (channel) state.  I suspect we can accomplish the same objectives as
> >>> Tracks and stay consistent with existing DetNet and TE(AS)
> terminology.
> >>>> 4) Is RAW limited to PCE-based centralized solutions?
> >>>>
> >>>> DetNet introduced the term Controller Plane to cover all types of
> >>>> control
> >>> supported by the IETF TE architecture, i.e., fully centralized, fully
> >>> distributed, or any hybrid combination of centralized/distributed
> >>> control.  The Architecture reads as supporting only one combination of
> >>> - PCE for paths, PSEs for tracks (aka protection segments) .   PSEs
> >>> read as also doing the actual protection switching, but this is
> >>> outside the scope of this comment.
> >>>> Hereto, I see no reason for the architecture to limit the scope of
> >>>> the Controller Plan solutions that could be standardized as part of
> RAW.
> >>>> (Yes PCE-based approaches are likely the first to be standardized,
> >>>> but that's not an architecture level decision.)
> >>>>
> >>>>
> >>>> Those are my top comments.  While substantive, I suspect addressing
> >>>> these
> >>> comments will result in some refactoring and rewording -- but not a
> >>> major change to the document.
> >>>> Thank you, and speak to you soon. (Unfortunately, just virtually
> >>>> this
> >>>> meeting...)
> >>>>
> >>>> Lou
> >>>>
> >>>>
> >> --
> >> RAW mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/raw