Re: [Tvr] [EXT] Re: First draft of problem statement

["Birrane, Edward J." <[e-mail]>]

Joel,

  Agreed - that is the point. TVR contributions (logic/analysis/models) benefit different use cases.

  I would not suggest that adopting TVR models means adopting the DTN architecture.  I do think those implementing the DTN architecture have a pretty apparent need for TVR models.

-Ed


Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Constellation Networking
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (C) 443-690-8272

From: Tvr <[e-mail]> On Behalf Of Joel Halpern
Sent: Monday, October 31, 2022 12:46 PM
To: Jorge Amodio <[e-mail]>
Cc: Dirk Trossen <[e-mail]>; Beck, Micah <[e-mail]>; [e-mail]
Subject: [EXT] Re: [Tvr] First draft of problem statement

APL external email warning: Verify sender [e-mail]<mailto:[e-mail]> before clicking links or attachments




If your point is to say that both conventional routing and DTN should be able to make use of whatever logic / analysis / models TVR develops to represent time variation, that seems fine.  I understood your point as saying that TVR IP Routing should support storing packets in routers when there is no current connectivity.  Routers essentially never store an undeliverable packet.  There are very good reasons for that.

Yours,

Joel
On 10/31/2022 12:11 PM, Jorge Amodio wrote:

In essence unless you do circuit switching, all packet switching networks store the packets in memory and you use routing information to decide where to forward the packets, the issue is how long you store them and if they carry routing data.

DTN needs routing and it is a prime use case for TVR, particularly in space communication applications.

-Jorge


On Oct 31, 2022, at 9:55 AM, Joel Halpern <[e-mail]><mailto:[e-mail]> wrote:


Generally working groups do better with narrow focus.

Having said that, my concern was combining the problem of routing adapting to planned changes with the problem of turning routing into a store and forward network (DTN does an interesting job there.)

Yours,

Joel
On 10/31/2022 4:28 AM, Dirk Trossen wrote:
Dear all,

Addressing by anything but an IP address does not need to lead to ICN like ephemeral storage architectures, though. Having the capability to deal with time-variant routing decision would greatly support ideas like ‘routing on service addresses’ (ROSA) (https://www.ietf.org/id/draft-trossen-rtgwg-rosa-00.html), which has been submitted to the RTG WG as discussion in the next IETF (scheduled now for the Thursday slot of the RTG WG).

Here, ROSA carries service information in IPv6 EHs for a shim overlay to make routing and forwarding decisions on that information. The selection of the appropriate IPv6 destination (called a service instance in ROSA) may be based on dynamic, down to request-level, decisions (we developed a simple round robin that can operate linked to computing information, as an example), but a time-variant decision may equally be useful.

The statement that “The larger value of TVR (IMO) is that a planned loss (or gain) of an adjacency can avoid tripping into recovery or rediscovery mechanisms.” is crucial and captures my understanding of TVR very well. But when thinking of routing on service addresses as an approach, the recovery/rediscovery mechanism may well look quite different when, well, routing on service addresses but network locators.

Best,

Dirk

From: Tvr <[e-mail]><mailto:[e-mail]> On Behalf Of Joel Halpern
Sent: 28 October 2022 20:06
To: Beck, Micah <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Tvr] First draft of problem statement


If the network holds packets for any significant length of time, this produces results which affect and disrupt the application behavior.  if you want a long term store network, look at the DTN work.  The applications themselves behave differently because they know that the network has different properties.  (One could even argue that the bufferbloat work shows that even the delays we have currently in the routing / forwarding network when we buffer for congestion cause application difficulties.)

This work is being considered in the context of IP routing.  And IP Forwarding.  The packets are addressed by IP.  The DNS or other resolution behaviors are driven by the applications at the end systems.

My understanding is that the goal of this work is to allow the routing and forwarding system to be aware of expected changes in the topology.  Changing the forwrading paradigm would be a different task.

Yours,

Joel
On 10/28/2022 2:00 PM, Beck, Micah wrote:
As I see it, the basis for route computation in DTN and IP is the known source and destination of the data, while the basis for route computation in ICN is the nature of the data.

Today, it is unusual for an Internet service request to be addressed directly by IP address - we use domain names (e.g. in URLs). A domain may indeed correspond to an IP address that names a unique network interface. However it is common for a domain to resolve to a set of IP addresses or perhaps to a single IP address that is routed to one of a set of network interfaces via BGP anycast. In either case, the network interface that is the target of the request is determined with reference to the network topology. If the topology changes, the target may become inaccessible or it may no longer be an appropriate one or the best choice.

As you point out, ICN copes with this kind of situation through content-based addressing. In contrast, requests that are resolved to an IP address can either be rerouted or they can fail. In the current environment, the resolution of a domain to an IP address is generally performed immediately before making a service request, so there is a limited window for serious changes to topology. If the target becomes unavailable, the request fails and domain resolution may be repeated before retrying.

However in the case of TVR, if data were to be held for a longer period at any point after domain resolution occurred, the topology could change quite dramatically. In this case it may be preferable for the service request to fail then to continue to try and reach the IP address originally targeted. It depends on many factors that may be difficult or impossible for the Network layer to take account of,

“The larger value of TVR (IMO) is that a planned loss (or gain) of an adjacency can avoid tripping into recovery or rediscovery mechanisms.“  I think this is an especially eloquent expression of what we are after.

Please forgive my ignorance on this topic, but how significant a cost is "tripping into recovery or rediscovery mechanisms”? Especially given the above analysis that such mechanisms are in some common and important cases used as an alternative to content-based routing as a way to find a target that is topologically well matched to a particular request.

There is an argument that use of topologically-informed domain resolution is now a means of service request routing. This has moved responding to major changes in topology out of the domain that the IP-address Network layer can deal with “completely and correctly”. That would mean it should be left to a higher layer. At least according to this argument.

/micah




On Oct 28, 2022, at 10:38 AM, [e-mail]<mailto:[e-mail]> wrote:

One direction I would like to try to steer us away from is conflating TVR with ICN.  As I see it, the basis for route computation in DTN and IP is the known source and destination of the data, while the basis for route computation in ICN is the nature of the data.  What I think distinguishes TVR (and DTN) from more familiar IP is (a) the way in which the route is computed, given the source and destination, in light of known future variations in adjacency and (b) how to enable the transmitted data to survive those changes in adjacency as it makes its way through the network.  The latter involves storage, as does ICN, but the operational context of the storage is different.

Scott Burleigh

From: Joel Halpern <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, October 27, 2022 9:40 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Tvr] First draft of problem statement

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]<mailto:[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]><mailto:[e-mail]> On Behalf Of Beck, Micah
Sent: Thursday, October 27, 2022 2:19 PM
To: vinton cerf <[e-mail]><mailto:[e-mail]>
Cc: Beck, Micah <mbeck=[e-mail]><mailto:mbeck=[e-mail]>; [e-mail]<mailto:[e-mail]>; Tony Li <[e-mail]><mailto:[e-mail]>; Rick Taylor <[e-mail]><mailto:[e-mail]>; Jorge Amodio <[e-mail]><mailto:[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]<mailto:[e-mail]>> wrote:


You don't often get email from [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:


You don't often get email from [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]] On Behalf Of Tony Li
>> Sent: 24 October 2022 21:12
>> To: Rick Taylor
>> Cc: [e-mail]<mailto:[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]<mailto:[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%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k84xSCnC2TMuvqIJXAZada8ZLP58ojrrFojmxMRe4tg%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]<mailto:[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%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>
>
> --
> Tvr mailing list
> [e-mail]<mailto:[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%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>

--
Tvr mailing list
[e-mail]<mailto:[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%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>
--
Tvr mailing list
[e-mail]<mailto:[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%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>

--
Tvr mailing list
[e-mail]<mailto:[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%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>
--
Tvr mailing list
[e-mail]<mailto:[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%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>





--
Tvr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tvr

--
Tvr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tvr