Re: [Tvr] First draft of problem statement

[Joel Halpern <[e-mail]>]

I would suggest being very careful about the path described below.  Not 
because it is wrong.  But because it seems to be a different problem.  
The DTN and ICN work deals with networks of devices which store things 
for later transmission.  To the degree that we are describing an IP 
Routing problem of reacting to changes in topology, that is not a 
storage and later transmission problem.  If we mix the two, I for one 
will find it quite confusing.

Yours,

Joel

On 10/27/2022 11:35 PM, [e-mail] wrote:
>
> Hi, Micah.  As you’ve reminded me (off-list communication), we have 
> been talking about this sort of thing for many years.  One way of 
> looking at it is to say that there is actually a fine line between 
> “communication” and “storage”.  Communication, in essence, is the 
> copying – to some location – of data currently stored at a different 
> location; in order to do this we usually first copy it to some other 
> (notional) location, which we term a communication “medium”. 
>  Interplanetary networking is a good example: the length of time the 
> data resides in the medium (which we no longer call “the ether”) is 
> the communication latency.  More prosaically, if I want to store a 
> locker combination very securely for two or three days then maybe I 
> write it on a piece of paper and mail it to myself.
>
> From this perspective, we might look at TVR as more explicitly the 
> selection of a sequence of locations to which we want data to be 
> copied; that sequence is a “route” and by acknowledging the storage 
> nature of the operation we tolerate variance in the timeline of the 
> copy operations.
>
> Scott
>
> *From:* Tvr <[e-mail]> *On Behalf Of *Beck, Micah
> *Sent:* Thursday, October 27, 2022 2:19 PM
> *To:* vinton cerf <[e-mail]>
> *Cc:* Beck, Micah <mbeck=[e-mail]>; [e-mail]; Tony 
> Li <[e-mail]>; Rick Taylor <[e-mail]>; 
> Jorge Amodio <[e-mail]>
> *Subject:* Re: [Tvr] First draft of problem statement
>
> Here are some thoughts about how the Transport and Application layers 
> might work in a TVR-based network environment.
>
> While some applications can work with the weak guarantees of a 
> best-effort network, providing a more robust model seems to be key to 
> adoption and growth. For this reason TCP does its best to ensure data 
> integrity, in-order delivery and to maintain connection state and 
> continuity in the face of interruption. TCP trades off these desirable 
> characteristics for increased latency.
>
> In the case of TVR, service interruptions may be more severe than are 
> widely acceptable to applications that use TCP. A TCP connection may 
> time out, or an application may simply fail to function adequately in 
> the face of a long enough pause in data transfer. For some 
> applications it is better to make weaker assumptions about network 
> availability than to make strong assumptions which are not satisfied 
> (resulting in error conditions).
>
> Is it possible for a Transport layer service to help overcome long 
> pauses in data transfer? The answer is yes, if that Transport layer is 
> willing to manage enough transfer state to enable some applications to 
> continue functioning during such pauses.
>
> A minimal example of an application that is “always available during 
> disconnection” is text messaging. Because the application buffers 
> messages until they can be sent, the end user experience is not 
> changed by a lack of connectivity. Interactive conversations 
> experience delays, but depending on end user expectation that may be 
> acceptable.
>
> The amount of state that would have to be managed depends on the 
> application. An audio streaming service might want the end system to 
> store enough music to get through a pause uninterrupted. A map 
> application might want it to store enough maps and instructions to get 
> to a destination. Applications that use larger data types (videos, 
> satellite imagery, executable images) might require substantially more 
> storage to enable continued operation during pauses in connectivity.
>
> All Internet Transport layers other than UDP manage state. TCP manages 
> send and receive queues. SCTP manages multiple queues. What I am 
> suggesting is more extreme, but enabling applications to work well in 
> an environment that does not provide continuous connectivity is a 
> major challenge.
>
> If it sounds like I am suggesting that some applications might require 
> multiple gigabytes of storage to enable continuous operations, that is 
> correct. However it is not necessary that the burden be located 
> entirely at a single end node. A large connection state could be 
> directed to a specialized storage appliance in the LAN.
>
> The intention of this proposal is not simply to enable asynchronous 
> data transfer in a sometimes disconnected environment, but to enable 
> as rich an interaction as possible using the Transport layer as a 
> stateful surrogate for a remote node. This might include enabling some 
> behaviors specified by the remote node. These would have to be limited 
> in scope for reasons of security and stability (not wanting to 
> recreate Java applets!)
>
> It is worth noting that the strategy of using edge storage and 
> processing to overcome connectivity issues is currently being pursued 
> by industry players, including Apple, Google and Amazon. However in 
> those cases the edge devices are closed and the resources are usable 
> only within the ecosystems of each company.
>
> The management of transfer state is part of the network stack. 
> Generalizing the Network layer without considering how this increases 
> the burden of responsibility on the Transport layer is leaving part of 
> the problem out of the picture.
>
> Best regards,
>
> /micah
>
>
>
>     On Oct 26, 2022, at 10:02 PM, vinton cerf <[e-mail]> wrote:
>
>
>     	
>
>     You don't often get email from [e-mail]. Learn why this is
>     important <https://aka.ms/LearnAboutSenderIdentification>
>
>     	
>
>     see delay and disruption tolerant networks (DTN)
>
>     v
>
>     On Tue, Oct 25, 2022 at 12:28 PM Beck, Micah
>     <mbeck=[e-mail]> wrote:
>
>         Hi all TVRers!
>
>         I am interested in using IP without latency bounds or minimum
>         connectivity requirements to provide digital connnectivity to
>         locations where broadband as currently defined by the
>         telecommunications industry will not reach soon, or perhaps
>         ever. I am seeking feedback on whether this category of use
>         cases fits in with the intended scope of the TVR working group.
>
>         In such cases, applications may use edge storage and
>         processing resources to hide or overcome high latency and
>         disconnection. An edge resource may have several possible
>         “last mile” links, and their endpoints may be predictable, but
>         the timing and availability may vary greatly even if there is
>         a nominal schedule. Thus, the topology is not as unpredictable
>         as MANET, but it has a great need for fault tolerance through
>         the use of multiple alternative last-mile links. It is similar
>         in some ways to cases handled by DTN, but I believe the timing
>         predictability assumptions are weaker.
>
>         Some examples include:
>
>         1. Connection through an aerial vehicle such as a blimp or LEO
>         satellite.
>
>         2. Storage carried on a ground or aerial vehicle that is used
>         as data transfer by moving it between a wired or wireless
>         point of connectivity to the backbone and the edge network.
>         Amazon’s Snow{Flake,Ball,Mobile} line of products are
>         proprietary Cloud versions of this “data ferrying” approach.
>         It has also been used in many specialized scenarios including
>         Wildfire Management scenarios and for email connectivity to
>         remote villages in India. Other examples that might take
>         advantage of scheduled ground vehicles include disaster
>         response (where National Guard vehicles could be organized to
>         move data in a predictable manner while also moving physical
>         good or people) or remote education (where school buses run on
>         predictable schedules reaching remote rural homes).
>
>         3. Use of links that are highly intermittent, noisy or have
>         highly variable transmission characteristics (e.g. error
>         rate). Various forms of underinvested community networking may
>         fall into this category.
>
>         In terms of how these cases may differ from what has been
>         considered in scope for TVR up to this point:
>
>         A. It may be necessary to utilize periods of connectivity of
>         very short duration, or which have characteristics that are
>         weaker than is generally assumed (high error rate for
>         example). This may require different transport or application
>         layer algorithms in order to take advantage of bandwidth which
>         is available (and which might be quite high in some cases).
>         This is not just a scheduling/routing problem but a
>         latency-tolerance issue.
>
>         B. If edge devices utilize a form of content-based or CDN-like
>         subscription to determine which data to transfer across the
>         last mile, then a routing scheme that is not based solely on
>         destination address may be necessary. A specific content- or
>         policy-based data movement policy might be implemented in
>         overlay, but it would still require access to low layer
>         topological and temporal information which may be held in
>         routing tables in order to make informed choices.
>
>         An example of case B arises when a large storage resource
>         (e.g, a ground vehicle carrying storage laden with deliverable
>         content) becomes temporarily available to an edge device (e.g.
>         parked within connectivity reach of a WLAN) but it is not
>         practical or desired to move the entire contents of the
>         storage resource to the edge device. We would like the
>         movement of data to be mediated by policy (which is not part
>         of the TVR mechanism) but informed by topological knowledge
>         that is available to the TVR routing algorithm.
>
>         Without case B, the hard-to-connect edge network must rely on
>         the same repeated unicast solution that is used in
>         overprovisioned networks.
>
>         My question: is this in scope for TVR, does it fit into
>         another existing framework or working group, or is it a
>         different category that would have to be considered separately
>         from the current taxonomy of stable, predictable or highly
>         dynanmic?
>
>         Thanks for your attention,
>
>         /micah
>
>         Micah Beck
>
>         Associate Professor, EECS
>
>         University of Tennessee, Knoxville
>
>
>
>             On Oct 25, 2022, at 9:45 AM, Jorge Amodio
>             <[e-mail]> wrote:
>
>
>             	
>
>             You don't often get email from [e-mail]. Learn
>             why this is important
>             <https://aka.ms/LearnAboutSenderIdentification>
>
>             	
>
>             I believe we are going to have stable, predictable/planned
>             dynamic, and random dynamic.
>
>             Jorge
>
>             On Tue, Oct 25, 2022 at 8:24 AM Tony Li <[e-mail]>
>             wrote:
>
>                 Rick,
>
>                 If you consider the cases of vehicle networks and
>                 satellites, both are highly dynamic topologies.  See
>                 the use cases document.
>
>                 Tony
>
>
>
>                     On Oct 24, 2022, at 11:20 PM, Rick Taylor
>                     <[e-mail]> wrote:
>
>                     Hi Tony
>
>                     I think dynamic topologies are for Manet to fix. 
>                     Here I think we are discussing stable topologies
>                     but with an extra time dimension.
>
>                     Does that make any sense?
>
>                     Rick
>
>                     Sent from my phone.
>
>                     On 24 Oct 2022 21:46, Tony Li <[e-mail]> wrote:
>
>
>                     Rick,
>
>                     One more thought:
>
>                     Our conventional mechanisms for protocol scaling
>                     have always been to create hierarchy based on a
>                     static topology.  A dynamic topology throws that
>                     out the window.  How do we achieve scalabity?
>
>                     Tony
>
>                     > On Oct 24, 2022, at 1:31 PM, Rick Taylor
>                     <[e-mail]> wrote:
>                     >
>                     > Hi Tony,
>                     >
>                     > Thank you very much - I found myself nodding
>                     along in agreement with all your points.
>                     >
>                     > I think I achieved my objective, which was (in
>                     combination with Ed's use-case draft) to start a
>                     conversation to discover if there are problems
>                     worth tackling here - and I still think there are.
>                     >
>                     > Cheers,
>                     >
>                     > Rick
>                     >
>                     > P.S.  I wanted to try to avoid using the word
>                     'topology' so early in a document - but I suppose
>                     this is the IETF so I could have got away with it ;)
>                     >
>                     >> -----Original Message-----
>                     >> From: Tony Li [mailto:[e-mail]
>                     <mailto:[e-mail]>] On Behalf Of Tony Li
>                     >> Sent: 24 October 2022 21:12
>                     >> To: Rick Taylor
>                     >> Cc: [e-mail]
>                     >> Subject: Re: [Tvr] First draft of problem statement
>                     >>
>                     >>
>                     >> Hi Rick,
>                     >>
>                     >> Thank you for your draft, it’s a good starting
>                     point.
>                     >>
>                     >> Some thoughts, in no particular order:
>                     >>
>                     >> Conventional routing protocols are somewhat
>                     less binary than you seem to
>                     >> imply.  You write:
>                     >>
>                     >> Changes to that
>                     >> connectivity, such as the loss of an adjacent
>                     peer, are considered to
>                     >>   be exceptional circumstances that must be
>                     corrected prior to the
>                     >> resumption of data transmission.
>                     >>
>                     >> In reality, of course, forwarding continues as
>                     best it can. Alternate routes get
>                     >> computed as quickly as is reasonably possible
>                     and forwarding continues. Link
>                     >> loss is a fault, to be sure, but is sadly not
>                     exceptional or an error in any way.
>                     >> This is primarily an issue of tone.
>                     >>
>                     >> There has been some work done to handle planned
>                     link (and node) outages.
>                     >> These have been operationally driven and to
>                     date don’t have a lot of
>                     >> management plane automation, but the techniques
>                     exist. Management sets
>                     >> the metric on the link to a very high value,
>                     effectively infinity, and traffic is
>                     >> diverted away from the link. Automating this
>                     would be one possible
>                     >> improvement that we could take on.
>                     >>
>                     >> You write that protocols assume:
>                     >>
>                     >> The individual nodes in a network do not move
>                     around.
>                     >>
>                     >> I think that the physical positioning of the
>                     nodes is not an issue. What matters
>                     >> is the topology. If you put a network on a
>                     fleet of ships and you move around
>                     >> and the topology stays connected, it’s not an
>                     issue.  When the topology does
>                     >> change, then yes, that’s an issue. Routing
>                     protocols do react to topology
>                     >> changes and they do not expect a topology to
>                     remain static.
>                     >>
>                     >> They DO make an inherent assumption about the
>                     rate of topology changes.
>                     >> Specifically, they are making the assumption
>                     that the topology is sufficiently
>                     >> stable that it is efficient and worthwhile to
>                     disseminate information about the
>                     >> topology change.  If the rate of topology
>                     change is extreme, then the cost of
>                     >> flooding and distributed computation may not be
>                     efficient.
>                     >>
>                     >> Moore’s law has been very kind to us. The cost
>                     of doing path computation has
>                     >> become almost irrelevant. True, the algorithms
>                     are still O(n log n), so scale is
>                     >> an issue, but modern processors have kept up
>                     reaonably well. Path
>                     >> computation is not an event to be feared.
>                     >>
>                     >> Modern forwarding practices have also made path
>                     computation less
>                     >> disruptive. When there is a link failure, there
>                     can be precomputed fast reroute
>                     >> paths that will take over the paths with little
>                     or no forwarding loss.  The use of
>                     >> ‘make before break’ techniques also allow us to
>                     make new path computation
>                     >> decisions without noticeable loss.
>                     >>
>                     >> One of the concerns that I have that doesn’t
>                     seem to be addressed is about
>                     >> link liveness and path computation in the face
>                     of scheduled uptimes.
>                     >> Specifically, can we be assured that a link
>                     will appear on schedule? Or do we
>                     >> wait until proof of liveness before directing
>                     traffic down the link? The former
>                     >> seems highly optimistic and potentially
>                     disruptive. Section 4.2 seems
>                     >> unnecessarily pessimistic. Our operational
>                     experience has caused us to be
>                     >> cautious about connectivity gains, especially
>                     due to flapping circuits. If those
>                     >> can be addressed in a particular environment,
>                     there is no reason that link
>                     >> creation cannot be handled as expeditiously as
>                     link failure.
>                     >>
>                     >> BGP does not require a global recomputation of
>                     topology. Which is a very
>                     >> good thing, as it has never converged. :-)
>                     >>
>                     >> I agree that having an Adjacency Schedule is a
>                     very good thing. Does it really
>                     >> need to be in the routing protocol? I’m not
>                     convinced. It seems like this is
>                     >> something that should be delivered by the
>                     management plane. I’ll say it once
>                     >> again: the IGP is not a dump truck.
>                     >>
>                     >> Regards,
>                     >> Tony
>                     >>
>                     >>
>                     >>
>                     >>
>                     >>> On Oct 24, 2022, at 11:17 AM, Rick Taylor
>                     <[e-mail]>
>                     >> wrote:
>                     >>>
>                     >>> Hi All,
>                     >>>
>                     >>> Right up against the deadline, I have publish
>                     a very early Problem
>                     >>> Statement draft at:
>                     >>>
>                     https://datatracker.ietf.org/doc/draft-taylor-tvr-prb-stmt/
>                     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-taylor-tvr-prb-stmt%2F&data=05%7C01%7Cmbeck%40utk.edu%7C0abfd7fe34a8457fd29c08dab7bf4b75%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638024329515744873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=H4CazsRc%2FhEnQk%2ByvhLg5BpQ3iPg72FrXd%2F6x8pLtOY%3D&reserved=0>
>                     >>>
>                     >>> Please feel free to read and comment, and I'm
>                     happy to use it as a basis
>                     >>> for discussion at IETF-115.
>                     >>>
>                     >>> Cheers,
>                     >>>
>                     >>> Rick
>                     >>>
>                     >>> --
>                     >>> Tvr mailing list
>                     >>> [e-mail]
>                     >>> https://www.ietf.org/mailman/listinfo/tvr
>                     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftvr&data=05%7C01%7Cmbeck%40utk.edu%7C0abfd7fe34a8457fd29c08dab7bf4b75%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638024329515901105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D%2F3atPNq4qtI1Zv2jcWRS73HwgNWP2V78V%2F8F9MRFzI%3D&reserved=0>
>                     >
>                     > --
>                     > Tvr mailing list
>                     > [e-mail]
>                     > https://www.ietf.org/mailman/listinfo/tvr
>                     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftvr&data=05%7C01%7Cmbeck%40utk.edu%7C0abfd7fe34a8457fd29c08dab7bf4b75%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638024329515901105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D%2F3atPNq4qtI1Zv2jcWRS73HwgNWP2V78V%2F8F9MRFzI%3D&reserved=0>
>
>                 -- 
>                 Tvr mailing list
>                 [e-mail]
>                 https://www.ietf.org/mailman/listinfo/tvr
>                 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftvr&data=05%7C01%7Cmbeck%40utk.edu%7C0abfd7fe34a8457fd29c08dab7bf4b75%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638024329515901105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D%2F3atPNq4qtI1Zv2jcWRS73HwgNWP2V78V%2F8F9MRFzI%3D&reserved=0>
>
>             -- 
>             Tvr mailing list
>             [e-mail]
>             https://www.ietf.org/mailman/listinfo/tvr
>             <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftvr&data=05%7C01%7Cmbeck%40utk.edu%7C0abfd7fe34a8457fd29c08dab7bf4b75%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638024329515901105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D%2F3atPNq4qtI1Zv2jcWRS73HwgNWP2V78V%2F8F9MRFzI%3D&reserved=0>
>
>         -- 
>         Tvr mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/tvr
>         <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftvr&data=05%7C01%7Cmbeck%40utk.edu%7C0abfd7fe34a8457fd29c08dab7bf4b75%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638024329515901105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D%2F3atPNq4qtI1Zv2jcWRS73HwgNWP2V78V%2F8F9MRFzI%3D&reserved=0>
>
>     -- 
>     Tvr mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/tvr
>
>