IETF 116 TVR working group meeting

Agenda

Monday 2023-03-27 06:30 - 08:00 (UTC)

Co-chairs: Tony Li (cTL, TL), Ed Birrane (cEB, EB)
Secretary: Adam Wiethuechter (sAW, AW)

Intro (10 min)

Administrivia: (Chairs, 5 minutes)

Bad joke by cEB to start. (great start, fantastic in fact)

Notewell check. You are being recorded and shall be posted.

Please sign in using Meetecho.

If you want to be in queue, even in room, please join the queue.

Please keep audio and video off unless presenting or asking question.

Please wear a mask if in room unless speaking.

Agenda bash.

Will start with schedule information and why/how use it.

End will be lining up document writing.

Charter and Scoping: (Chairs cTL, 5 minutes)

White on white for slides...what a concept. (another bad joke, 2/2 is
this a trend?)

Ground rules - play nice. Focus on goals

Goals

• making all docs on slide

Non-goals

• not every use case

  • do not care about trivia

• transport protocols (rtg protocol is not a dump trucks)

• Not modifying routing protocols
  • Up to other WGs
  • Could take requests to them
  • Recommend behavior

Write a draft! Give presentation! Discuss on list!

cEB: any agenda bash? nope lets move!

Presentations (65 min)

TVR Use Cases Review (Ed Birrane, 5 min)

https://datatracker.ietf.org/doc/draft-birrane-tvr-use-cases/

When did BoF wanted a few use-cases of what trying to accomplish and
their benefits.

Use-cases can be used as rubric for future work.

Case 1: local resource preservation

• sense of schedule awareness leads to local resource preservation

Case 2: adapting to external conditions

• total cost of ownership can be limited when knowing high/low cost
  uses

Case 3: mobile devices

• predicted mobility
  • distance, antennuation
  • planned topology changes

Poll: Should these use cases be in a info rfc?

• 42/1/43

Marc Blanchet (MB): i like use-case info docs if they go clearly into
requirements

cEB: fair and noted. still would go through wglc and make sure it work.

Volunteers? multiple authors are good.

The AIXM temporality model and TVR (Emery Annis, 10 min)

https://aixm.aero/sites/aixm.aero/files/imce/AIXM51/aixm_temporality_1.0.pdf

On behalf of Brian Sipos.

Background on aero temporality model. existing time variant info model.

Temportality model

• need to convey time based, schedule information
• common language to understand and bounds
• absolute and periodic time
• completely abstract of producers and users of info
• state of system, feature or propery
• not why state changed
• different industry with a lot of work and lessons learned

AIXM origin

• link on slide
• Aero Info Exchange Model (AXIM)

• need of conveying time variant info

  • wrote a separate piece

• notice to air mission (notam)

• concept been used a planning tool for cruise liners connecting to
  geo sats

Model structure

• feature and its properties

• runway

  • time can be used
  • state

• planned

Terms

• see slide
• model supports both permanant definition over time and temporary

Example

• baseline with start and end of life
• clear state changes
• temporary values
• update baseline with perm deltas
• describes conflict resolution for model

Repetition

• periodic behavior in schedule

Parameter interpolation

• parameter values discreet for axim
• express as function

Horizontal concept

• planning horizon
• horizons can be very short
• not part of datamodel, but maybe use case

For TVR

• express parameters over time concept
• gives them ability how to consume information

Conclusion

• go read axim model
• check concepts
• if datamodel for tvr see if we can borrow concepts and language

Jorge Amodio (JA): model free?
EA: published and free to use it
Toerless Ecket (TE): mentioned something as a function rather than
table? worse case example in axim? very interesting for tvr.
EA: is granularity so small that there are 1000s of states over a short
period of time. details would need to be worked out - how to negotiate,
etc. They did not do that they left discret.
TE: following antennas?
cEB: lets move,
Q Misell: does axim a mechanism for confidence of data in model
EA: language and examples in UML for how to convey. It could be added.
shouldnt be part of info model - so users can decide them.

Time Variant Scenarios in the TIDAL network (Li Zhang, 5 min)

https://datatracker.ietf.org/doc/draft-zzl-tvr-use-case-tidal-network/

Tidel effect of traffic on networks

• slide showing the behavior of traffic

Assumptions

• traffic is predictable
• algorithm to disable nodes for scale of traffic
• data model with time-based info
• collection and advertisement (sharing?) of data model
• routing is based on data model

Example / problems to solve

• how do we describe time info into a data model?
• new routing algs? avoid packet loss during changes

A Brief History of Contact Graph Routing (Scott Burleigh, 15 min)

No Draft

Deep space

• wireless signal

• long distances (with physical limitations)

  • low data rate
  • omni-directional transmit
  • high latency
  • no negotiation

• low capacity

• small ground station supporting many spacecraft

  • they all move (rotate on axis or orbits)
  • body fixed antenna
  • signal interruption is routine
    • AW: no end to end connectivity!

• overall

  • limited
  • async
  • expensive
  • precious

• ground pointing to space is "tracking"

  • ethernet cable you plug and unplug
  • command of ground station and spacecraft in tandem
    • based on schedule
    • "pass plan" - file

Except of Ulysses pass plan

• routine for spacecraft comm operation

Mars relay

• more complex
• relayed instead of direct comm back to earth
• rover to orbitter (as relay) to earth

Contact plans

• generalization of "tracking passes"

• representation of time-vary topology

  • schedule distributed
  • managed and authoritative
  • managed knowledge of physical topology of network

• example graph and table

  • overlay of table to graph

• looks like routing table - but NOT

  • map of time varying network topology
  • no routes

• learns routes between nodes using contact plan

  • similiar to BGP

Contact Graph Routing

• way to use info from plan to compute routes
• directed graph

Example of CGR

CGR routing table

• list of complete routes

  • not next hops

• max utilization is very important

• shortest usable route is best

  • if none, recompute to find and if not found discard

• load balancing with recomputation for utilization

Chronology

• 2007 with ION
• DINET experiment
• on ISS since 2016
• internation standard in CCSDS
• alternative method is proposed

cEB: can we present such thing at another meeting?
SB: yes!
cEB: thank you for the history. no queue questions.

Forwarding in the Context of TVR (Marc Blanchet, 10 min)

https://datatracker.ietf.org/doc/draft-blanchet-tvr-forwarding/

Rationale

• space comms
• BP in Swift for Apple and linux
• policy forwarding bundles
• BP is store and forward
• what do you do with bundles for forwarding or dropping?
• generalized from BP to IP
• packet and bundle interchangable in these presentations

Forward

• stored and saved with timestamp
• when route states changed things are sent that can be

Policies Needed

• packet memory full already

  • drop?
  • remove old?

• what is sent first?

• expired packet

• storing may be demanding

  • preference what is stored

• when dropped error to source

  • could be costly to do
  • what if too old and error irrelvant

Drop Policies

• list, enum
• drop oldest
• drop last from these sources
• drop last for these destinations
• drop last based on field of packet/bundle
• error reply? (never or if not too old)

Forward Policy

• link back
• which do i forward first?
• first from these sources
• first to these destinations
• first based on field of packet/bundle

Comments

• Why IP? use-cases with little delay but still need time-variance
• should do a Yang model
• Weighted concurrent policies
• Default policy?
• define header fields that would be instantiated in policies

WG adoption and comments

Rick Taylor (RT): if not in scope here can be in dtn. Very relevant in
BP. Open to suggestion from floor if TVR handles this.
cEB: please take to mailing list!
Erik Kline: sceptical useful for IP, will go to list
Ron Velt: forsee support opportunistic routing? lots of work out there
already. PROFIT.
cEB: that is not in scope for TVR. we can take to list.
RV: strange but okay.

A Contact Plan Data Model (Marc Blanchet, 10 min)

https://datatracker.ietf.org/doc/draft-blanchet-tvr-contactplan/

Rationale:

• everyone has different model...ugh.
• document to do this!

Example in JSON

• contacts have uuid

Comments

• Yang (Dean and Tony) - Dean offers to help
• unnumbered links: agreed
• top level id and for each index or only id in records or both. to be
  discussed
• empty list of contacts: ok

• list of dests

  • for dtn-bp, no prefix like ip/cidr

• time start/stop: may state one is mandatory, or even none to support
  incomplete contact plans

• bandwidth/latency: bandwidth used in BP. might remove latency as
  layer violation.
• convergence layer syntax: requested and agreed.
• No need for format (Scott Burleigh), ok for data model useful.
  format is up to implementor
• probability of contact: to be looked at. used in some BP
  implementations

Thanks for early review, WG adoption and comments.

RT: implemented similiar in manet, split metrics away from links
(common). Have dynamic sets of metrics. Some metric may show up so flex
is good. Support adoption, needs work but in good direction.

Using ALTO for Exposing Time-Variant Routing Information (Luis Contreras, 10 min)

https://datatracker.ietf.org/doc/draft-contreras-tvr-alto-exposure/

Rationale

• predictable chnages fo TVR
• comes from higher level systems (OSS, network controller)
• can anticipate impact
  • algorithms with experimental observations

Calendared topologies

• ALTO [RFC8896]
• cost calender
• attributes to describe scope

ALTO for TVR

• enable TVR info to applications

  • assess to solve

• define how ALTO can participate to routing process

• data model(s) leveraged for ALTO

Relevance

• Attribute parameters used as input for data models

• cost calender use case

  • apps use the data in the calender

• collect feedback

Wrap-Up (Chairs, 15 min)

Goal behind discussion and presentation; cases and existing work dealing
with schedules

Find commonalities.

Turn into drafts.

Have information use-case document.

Need people to start working on these things.

Go to mailing list, who is interested in what pieces and consolidate
around ideas. Start to collab so there is drafts for next session.

Call for Authors: 5 min

Walk-On Topics: 5 min

Final Comments: 5 min

Open Mic

Dean: info model is somewhat been defined based on Marc document and
other presentations. Lots of options requirements. Well defined for
space; more terrestial use-cases.

cEB: agreed

Stu Card: may have missed; probability!!! predictions and have
uncertaintity. Where is this? We have explicit representation of
confidence/probability?

cEB: agreed and noted to discuss on list

Lou Berger: dont understand all link attributes for schedule. opaque
attributes. use-case, requirements? We defintely need

cEB: heard and agreed. multiple radios, how to distinguish?

cEB: almost 100 people, clearly something with lots of interest. Active
on mailing list and coordinate on drafts! We will see you all in a
couple months. Understand reqs and info models for time variant
information.

eEB: closes with another terrible joke. it is a trend and as it should
be.