I-D: https://datatracker.ietf.org/doc/draft-ietf-tiptop-usecase/
Slides
Presenter: Benjamin Dowling
MartinD: Are there existing protocols that meet these requirements?
BenjaminD: Yes there are protocols that do support, but the one
describing QUIC doesn't quite address PFS/PCS. MLS does.
RickT: They are all generally sensible, but for bullet 3 (group comms)
questioning whether that is critical?
BenjaminD: PCS & PFS is more core, but use of enclaves in space would be
a nice property to have.
As noted in the chat, there are some existing documentation we could [
pull from | refer to ]:
https://arxiv.org/pdf/2503.06785
https://ccsds.org/Pubs/350x1g3.pdf
Slides
Presenter: Natia Piotrowski
MarioP: Small suggestion for recovery metric maybe use the medium
throughput prior to the outage to be more agnostic?
Zahed: Is this conversion because of the setup? Can I do this with lower
RTT. We need to know what the other parameters. Should look because of
settings for the moon or not.
LucasP: Thanks for doing this! If you find a bug, I'll fix it!
MarcB: IMPLICIT but you received all the data correctly? (yes) There was
no data loss.
Natia: Well there was some packet loss, but it was fully recovered.
MarcB: When there were outages there was no buffering during outages.
What if you buffer would it change results?
Natia: Would need to look at that.
Slides
Presenter: Marc Blanchet
MartinD: The fact that you do smells liek a NAT issue. But, about the
intermitant links. This is seconds of outage.
MarcB: We did 15m on then off.
MartinD: What is that emulating?
MarcB: We should have gone longer.
MArtinD: Meant to emulate the orbiter going on the other side of the
world. (yes)
DavidL: IMAP using works over these kind of networks.
MarcB: WE didn't look into it too much.
JinyouD: You should add a top layer.
SandraC: If you turn off the there's a buffer and the packets are being
told. In real life you'll totally lose the packets.
MarcB: ...
I-D: draft-many-tiptop-ip-architecture
Slides
Presenter: Wesley Eddy
BrittaH: QUIC is in the draft. Should not be looking at a call for
adoption unitl we address this?
Zahed: How much detail do we need in the I-D still needs to be decided.
JoergO: Architecture draft is a good place to document that things get
out of the box.
SandraC: Yo show there's going to be information of kinds of link layer
technology. If you have a forwarder, then there has to be a standard way
to expose the link scheduling info to the TIPTOP forwarder.
JadC: I don't see that much happening out there: 1 you are saying
addresses should come from RIR? 2. Which one or more? In RIR space is
governed by community policy. Should take it to RIR to start the
communication. Need to address the 32 bit elephant in the room - we
don't have any so ... maybe we should take a stand and be v6 only.
WesE: Recommendation arch doesn't hinge on it.
TonyL: I haven't done anything with the comments I got. We're not gonna
pick the RIR, but it's not up to the IETF. We could do one or the other,
but we just need to agree.
BrittaH: Is the I-D is supposed to be an arch or specify protocols?
WesE: We can maybe fix that from an editorial perspective. QUIC is not
the only one.
DavidL: You need to push addressing out of the I-D.
RickT: Carrier grade NAT is going to have an impact.
MartinD: We know it will be more effort.
EricV: Same comments as MartinD. Why is MPLS there?
BrittaH: Whole section on handshakes - not sure it should be there. Some
of the recommendations seem to be insecure. Either we need to take it on
or you need to remove text.
MartinD: Current the draft is better on requirements.
Poll: 22 read draft, 26 didn't, and 2 didn't know.
Slides
Presenter: Juan A. Fraire
No discussion / running out of time.
I-D: draft-gomez-tiptop-coap-00
Presenter: Carles Gomez
Slides
No discussion / running out of time.
If time permits
Jöerg Ott (10 minutes)
No time.