Please help capture comments/discussion in-line below
IETF 115 TVR BoF Minutes
Version: Nov 10, 2022
Thursday, November 10, 2022
09:30 - 11:30 Thursday Session I (London local time, UTC+0)
Materials: https://datatracker.ietf.org/meeting/115/session/tvr
Note taking: https://notes.ietf.org/notes-ietf-115-tvr
Meetecho:
https://meetings.conf.meetecho.com/ietf115/?group=tvr&short=tvr&item=1
Audio stream: https://mp3.conf.meetecho.com/ietf115/tvr/1.m3u
Zuilip: https://zulip.ietf.org/#narrow/stream/tvr
WG ICS: https://datatracker.ietf.org/meeting/115/sessions/tvr.ics
Session ICS: https://datatracker.ietf.org/meeting/115/session/30001.ics
- Chairs: Lou Berger, Russ White
- Secretary: Yingzhen Qu
- Note takers: Adrian Farrel, Daniel King, Russ White, Eve Schooler,
....
Available post session:
Recording: http://www.meetecho.com/ietf115/recordings#TVR
Jabber log: http://jabber.ietf.org/logs/tvr
1) 09:30 10min Session Intro
Presenter: Chairs and AD
- Lou Berger: Note well. The agenda is different from what was posted
a couple of days ago.
- Lou Berger: Agenda timings are deliberately approximate
2) 09:40 ~15min Time Variant Routing Problem Statement
Presenter: Rick Taylor
Start time - 9:36
- Kevin Fall: I worked on this 10 years ago. Internet routing has
roots in 1958 publication from Ford Fulkerson and Dijkstra. The
operations research community looks at the same problem space.
Consider dynamic trans-shipment problem which is a similar set of
problems, but solutions could be very different (e.g., could packets
live in a buffer for a day in transit?)
**See: Constructing Maximal Dynamic Flows from Static Flows, Ford
Fulkerson, https://pubsonline.informs.org/doi/abs/10.1287/opre.6.3.419
- Rick: First, existence of research is a good thing. Existing
problems and solutions can inform us. For stable network in the
internet, we're very familiar with it, and I'll talk about Manet
later. Approaches like timetables for rail system can give us info.
- Lou: We will have time at the end for Q/A but already we have eight
people in the queue, so we will need to cap questions now to
continue with the agenda.
- Alex Clemm: Missing "what would you do with this information?" This
is missing from the problem statement, better be explicit.
-
Rick: Fair. Quick answer is there is an opportunity if we know
something is going to change, we can save time and network resources
not getting things wrong or tracing faults. There are various use
cases in IoT and Space(based networking) where we need to know about
availability of links in advance. If we know something is going to
change we can do the calculation ahead of time.
-
Tony Li: See mailing list. Are we covering dynamic topology? If not,
the problem is quite straight-forward and we already have techniques
dealing with links taking out. If a link is scheduled to come up, do
we wait on liveness information to propagate to declare the link up.
- Rick: If a schedule is going to be up, it would be a mistake to
believe it. We always have to deal with failures in routing
protocols. The "dynamic question" is a scoping question: I think
start simple, but don't discount more complex situations
- Lou: I think you already have this dynamic topology in scope on your
slides (on slide #2, for example, peers changing or new links coming
up T2 and T4.)
- Rick: MANET "dynamic" can be very chaotic, so I tend to avoid the
word, but "yes" in this scope if the links come down and up and
nodes move around if it has corresponding predictability, we are
talking about dynamic topology
*Russ (chat): this does cover dynamic topology cases; service
reachability is the issue, not the specific path to reach that service
-
Erik Kline: like bus or train schedule, it's related to drive
directions, special and different from today's routing and deserves
a space to consider it
-
Julian Lucek: This BoF is timely for me. I recently came across a
n/w with remote sites with a single fiber and a fiber switch on the
access so that the site border router can be changed.
-
Rick: This is another example of the same kind of use case. It's
reducing the data transmitting capability when something happens. if
you know what to expect, you can be ready for it. I don't know if
this isn't solved, but I don't think it is.
*Scott Johnson (chat): The concept of neighbor discovery needs to be
included
- Andrew Alston: I live in part of the world where power is not always
stable. I can do fast reroute, but if I can know the schedule for
power outages, how I react can depend on what I know about the cause
and duration of the outage. So knowing may allow planned rebalancing
which is importantly different from people in a remote NOC who might
just think it is a temporary router failure. Additionally, learning
algorithms may be able to make good use of this info and act
accordingly. I see lots of possibilities and am extremely interested
in this.
-
Rick: Don't get caught up on how to create schedules. But once we
have a schedule and work out how to get it around the network we can
do a lot.
-
Dirk Trossen: Perhaps there are different variants to consider.
Other dynamic conditions under which you might want to change your
routing.
- Rick: I take your point, but I don't want to boil oceans. I also
don't want to get to ECA and network programming. I agree with your
points, but I just want to focus on what is achievable in a
reasonable scope.
- Lou: Just to be clear it will come up later that other things can
change, such as bandwidth, energy, etc.
- Rick: we have use cases for that later.
- Dirk: Yes, it could be driven by energy costs, and use contextual
information that could be boiled down into the scheduling API.
- Rick: completely agree. it comes down to whether we have a schedule,
and whether we can define the schedule.
- Edward Birrane (chat): There are use cases that include other
factors that change, such as power, cost, etc.
-
Rick: Defer to later presentation
-
Stewart Bryant: When a node or link changes, there is transience.
Can we minimize disruptive effects of micro loop changes (due to
rate of FIB updates)
- Rick: Yes, if we can plan for future outages, we can plan to work
around microloops. we can pre-agree on topologies to avoid those
microloops.
- Stewart: Not simple because of convergence of FIBs. Thus we need a
process of changing topologies
- Rick: Yes. This should be in scope. Can we describe "in general
terms" how to do this? Then we can move the solutions to the (e.g.)
IGP working groups
- Stewart: these techniques were documented in the routing area years
ago in RTGWG.
-
Russ (chat): this also applies to higher performance situations,
where the application can know about scheduled events, hence
adjusting timers to anticipated temporary changes in delay/jitter
-
Zulip/Jabber
- Dirk Trossen: This being called 'time variant routing', let me
ask a maybe silly question: is time
- the only predictable dimension of variance in routing we may
care about? Or may we care about other predictable changes to
routing (e.g., based on locality)?
- Lou Berger:@dirk at least some is in scope, think a fair
question to ask at mic
- Abdussalam Baryun:good question
- Russ White:this also causes us to ask some other questions, like
"how do I know about resources that are not currently not on
line?" ...
- Scott Johnson:dynamic routing is rather critical, from the input
we have gotten from the community.
- Adam Wiethuechter: Knowing if a resource that is far better for
me t solve a problem is offline, but I know will return at a set
time, I now must weigh if it is worth waiting for said resource
or spending additional resources that are ill-fit to the problem
I am currently facing
- Russ White: this should deal with the dynamic topology ... the
key is reachability to a resources across any path ... the path
might change
- Jorge Amodio: of course you can have failures but think about a
satellite that passes over a given point every x number of time
units
- Daniel King: Good question. Do we need to consider a
reliability, or probability, of the link being available at a
scheduled time.
- Scott Johnson:the concept of neighbour discovery needs to be
including in this thinking as well, adding to the definition of
dynamic.
- Lou Berger: also change in other metrics, e.g., delay, loss
probability, available data rate
- Joel Halpern: The presenter just alluded to a question that we
should be clear on. What time scale and precision of timing are
we concerned with? He said "not nanoseconds".
- Jorge Amodio: I believe it is way longer, perhaps days
- Tony Li: If we agree that we want liveness, then 'not
nanoseconds' is a given.
- Daniel King: Yes, at least for LEO, UAV, we are considering
minutes, hours, days.
- Jorge Amodio: deep space as well
- Daniel King: Months :-)
- Jorge Amodio: SSI - Solar System Internet is slowly evolving,
and we don't have yet a routing solution
QUEUE CLOSED
3) 09:55 ~15min Use Cases
Presenter: Ed Birrane
Start time - 10:05
All questions deferred to item 3.3.
3.1) 10:00 ~15min Topology Management Challenges for Satellite Constellations
Presenter: Dan King
Start time - 10:21
All questions deferred to item 3.3,
3.2) 10:35 ~15min Carbon-Aware Networking Use Case
Presenter: Eve Schooler
Start time - 10:33
All questions deferred to item 3.3.
3.3) Discussion of all three use cases presentations.
- AB: This is interesting and I'm willing to help. Proposed solution
is not clear. Are we only changing the metrics or also the
algorithms? We should also be clear on the conditions and stability
of routing mechanisms.
- Russ: We need to work out the use cases and models and then push
these to the protocol working groups to work out what to do with
them. We're trying to get to the point of solid use cases before
dealing with solutions.
- Dean Bogdanovic: Seen this at several recent IETF meetings. It is a
big multi-dimensional problem. IETF might not have enough expertise
to handle all dimensions. IRTF might be a better place until we
understand the problem.
- Lou: One challenge is "What does the routing area do?" Transport
area had a side meeting, it's a big problem, so other Areas may need
to work
- Dean: It's a big problem, you have to define a policy, and then how
to enforce this on the network
- Dan: I disagree. This is not an IRTF problem. This is an engineering
problem, and I see this being applied to existing infrastructure.
- Dan: I see some commonality with these use cases and we have a
current draft in the routing area; perhaps we can work together.
- Mallory Knodel: I want to support this work. I think this has to be
mainstream in a lot of the IETF, not just one place. In IRTF, we
talked about how to reduce footprints, and sometimes the source of
the electricity might also be a problem. There needs to be a general
approach to reduction and minimization.
- Lars Eggert: A principle we might use to narrow the scope. Can we
limit to scope where changes to topology happen in a percentage of
the RTT (so as not to overlap with similar function in transport)
- Joel Halpern (relayed by Lou): What is the scale of timing we are
talking about?
4) 10:55 ~15min Technology Gaps / Potential WG Topics
Presenter: Rick Taylor
Start time - 10:55
6) 11:10 10min Open Discussion
Based on the chat dialog, there is some difference of opinion on whether
multicast and multi-path should be in vs out of scope.
Start time - 11:11
- Kevin Fall: Lars reminded me a bit what happened, when DTN was a
research group, we intentionally confused the acronym, D could
delay, disruption or whatever, so the research would be in scope.
What is the scoping defintion? Maybe to refine that, we can ask what
is the covering? There are use cases, the space example also have
overlap with underwater that are 5-times in order of magnitude. If
your going to separate the store and forward, what is the connection
to scheduling, knowing what paths, places and storage exists also
important. properties of nodes along the path are also important,
reliable or not, whether it's in a geography we can trust etc. that
might be out of scope. The richness, we have discussed over years.
- Brian Sipos: One thing we haven't talked about is on the management
side there are things like NetConf which has running datastore vs.
candidate datastore, but you can't schedule them, you only get one
of them. When multi-tenancy comes into play, don't want a separate
mgnt org to handle the scheduling and time rates for every time
something changes.
- Lou: At a WG earlier this week, someone pointed out there are
building blocks to creating schedules. We definitely want to reuse
where possible.
- Toerless Eckert: One question is how to get from here to running
code that would be useful. If one way to get there is to build a
system using mainly existing IETF components, this would be good to
show as the goal. We have examples of WGs how this has been done (cf
ANIMA). If this is more fishing, with a big system design then we
have experience with SIGs (see MOPS and IOTops). Just as a process
recommendation.
- Lou: Thanks for that, after the meeting we will review and see what
will happen. We met with Alvaro and what you see is potential work
items we already identified, we need to see if these are relevant.
We need to identify items that are deliverable and actionable.
- Toerless: as a contributor I'd like to see how these components can
work together.
- Rick: I see that. The result should be these are relevant pieces and
how they work together.
- Jari Arkko: I like this. Cool. We should do it. Interesting use
cases. Caveat: there may be chicken and egg... Schedule creation is
out of scope is good as local optimization might not be for other
cases. Energy is an interesting and complicated case, you have
various aspects of power and techniques to consider, such as
implementation where a node could be in a low-powered state, so you
can reduce energy, or you can be totally off, and then you dont have
to tell anything to the network. Some use cases are clear, like
satellite where you turn completely off and continue to rotate
around the earth, while some others might be more complicated. My
suggestion is to focus on the easily defined use cases.
- Adrian Farrel: Want to agree and disagree with Lars. I want to agree
that there is part of this problem space is the time variant
provision and awareness of service points and direction of Transport
paths and I want to disagree because I Think this is about packet
routing inside the network. Transport is an overlay over packet
routing. Both have a part to play, so we need to do an analysis of
both problems, and work out which ones we are solving and then work
out where to solve them, and not just use the existence of one
problem to say well you can't talk about the other problem
- Dean Bogdanovic: It's an interesting problem, but don't make it a
kitchen sink for all problems. Let's work out what we can solve. If
we try to add all possible things in, we will get lost.
- Rick: agree. One we can't schedule the whole internet, second we can
only achieve what's achievable.
- Colin Perkins: (no hats) There has been a lot of previous work and
research. Reasonable to explore whether we can do a focused work.
Echo Lars, think about time variance and link latency to scope the
problem. Will also tell you whether you need to solve transport
problems. Space and underwater networks have radically different
properties, make sure you have the right subject experts involved.
QUEUE CLOSED
============================
{: id=""}
Polls - Room had 134 people, according to MeetEcho.
-
Are you interested in seeing this problem being worked on in the
IETF? (Raise hand for yes)
Raise hand : 74 / 94%
Don't raise hand : 5 / 6%
More than half the room have raised hands for Yes.
-
Do you think a new Routing WG is needed to work this problem? (Raise
hand for yes)
[Note: may be other WGs in other Areas]
Raise hand : 64 / 74%
Don't raise hand : 22 / 26%
Good percentage of folks responding, with majority saying yes.
Some question about whether it should be in Routing, or in multiple
groups.
-
Are you willing to contribute as an author or reviewer if a new WG
is formed? (Raise hand for yes)
Raise hand : 65 /86%
Don't raise hand : 11 /14%
7) 11:20 10min Wrap Up / Summary / Next Steps
Presenter: (Chairs, AD, IAB Shepherd)
-
Andrew Alston : These are not votes, but just indication. I read
this as "maybe this should be in routing, but whatever, I am willing
to work on it"
-
Lou: I think that's reasonable. There might be more WGs.
-
Alvaro Retana (responsible AD) : Is there interest? Yes, people are
here and the polls. People think there are problems and are
interested to solve and contribute. We need to scope down the
problem. This was a non-WG forming BoF to gather use cases and area
of interested. The potential area is very wide and we need to scope
it down to things we can work on and are clear. Need to discuss this
on mailing list. What are the (small number of deliverables) and
move forward.
-
Mallory Knodel (AD shepherd) : Where else is this work happening? Is
some of this ITU-related. Need to gather this info. great to see all
the interests and that's a strong sign.
-
Lou : please continue this energy on the list. We will work with
IESG and IAB on next steps. Thank you for this successful session.
Meeting ended - 11.33
==> There is very substantial discussion in the Zulip chat alongside
this meeting. Readers of these minutes should also read that chat.
Adjourn 11:30