[deepspace] Re: A possible TIPTOP deployment question: traffic crossing heterogeneous network boundaries

[Alexander PELOV <[e-mail]>]

Dear Marc,

Well, it is a “change of segment” problem. If everything remains on Earth, no changes are needed.
The question is when a packet is about to cross from Earth to an interplanetary link. (Or from IP to LPWAN link)

It is at that point that you want to take some actions.
For example, to be able to signal - in authenticated way - that the next hop(s) have very special characteristics.
(You may, in addition, want to drop packets that are not tagged in some way indicating that they are intended for such characteristics)

Of course, you may simply drop the packets with ICMPv6 Destination Unreachable message (Type 1, Code 1) - but as far as I know, there is no way to signal to the source what is the expected behavior from the traffic - in an authenticated way. 

In any case, ICMPv6-SEC, or other solution, I think the question is there - how to handle traffic which is not aware, or not supposed to cross to Mars?

As I said, the draft tries to frame the question and provide a possible par of a solution. It is by no means the only solution - and it is not the full one. I think there may be several complementary mechanisms. 
In any case, I feel that the natural way of handling this on the network level is through ICMP.

Cheers,
Alexander




https://imt-atlantique.webex.com/meet/pelov 	Alexander PELOV
Associate Professor
02 99 12 24 11Technopôle Brest-Iroise CS 83818
29238 Brest Cedex 3
La Chantrerie 4 rue Alfred Kastler BP 20722
44307 Nantes Cedex 3
2, rue de la Châtaigneraie CS 17608
35576 Cesson Sévigné Cedex
 <https://www.imt-atlantique.fr/> <https://www.facebook.com/IMTAtlantique> <https://www.linkedin.com/school/24772587/> <https://www.instagram.com/imt_atlantique/> <http://www.imt-atlantique.fr/l-ecole/actualites>
Une école de l'IMT <https://www.imt.fr/>



> On 25 Jun 2026, at 23:10, Marc Blanchet <[e-mail]> wrote:
> 
> 
>> Le 25 juin 2026 à 15:41, Alexander PELOV <[e-mail]> a écrit :
>> 
>> Dear Marc,
>> 
>> Thank you for the detailed reply!
>> 
>> I was thinking about performing this potentially “intrusive” processing while the packets are still on the same planet- for example, dropping a packet at a point where the sender is still only a few hundred milliseconds away.
> 
> Ok. Then that looks like a generic terrestrial Internet problem. Don't we (IETF) already have a solution for that? Thinking...
> 
> Remember that ICMP messaging from intermediate nodes to sources is typically disabled (or severely rate-limited) in networks, for various reasons. 
> 
> Marc.
> 
>> 
>> This is exactly as you describe it: performing the filtering and signaling before the traffic enters the constrained link.
>> 
>> Such a policy could, for example, apply to Mars-bound traffic, but not necessarily to Moon-bound traffic. 
>> The sender would then be informed that its current configuration is unsuitable - for instance, that attempting to establish a secure connection to Mars with a five-second expiration timer cannot work.
>> If the sender cannot adapt, perhaps because of a configuration error, the traffic would not consume capacity on the interplanetary links or contribute to queues in the network around Mars. 
>> If it can adapt, it could potentially do so within a few hundred milliseconds.
>> 
>> The same mechanism could also trigger a user interaction, such as: 
>> “This connection would currently cross a path with an RTT of approximately 40 minutes. Do you want to continue?”
>> This is clearly beyond the scope of the draft. I am simply trying to understand whether scenarios of this kind make sense from an operational perspective.
>> 
>> Once the packets are already orbiting Mars, I agree that dropping them would be undesirable without an additional reason. Such a reason could be, as you mentioned, that queues are full and some traffic must be discarded according to policy.
>> 
>> Looking further ahead, one could imagine a traceroute-like mechanism that discovers whether a route crosses any special or constrained segments. Alternatively, even a simple explicit probe - perhaps similar to ping - could cause segments along the path to return ICMPv6-SEC notifications to the sender.
>> 
>> Cheers,
>> Alexander
>> 
>> 
>> 
>> 
>> https://imt-atlantique.webex.com/meet/pelov Alexander PELOV
>> Associate Professor
>> 02 99 12 24 11
>> Technopôle Brest-Iroise CS 83818
>> 29238 Brest Cedex 3
>> La Chantrerie 4 rue Alfred Kastler BP 20722
>> 44307 Nantes Cedex 3
>> 2, rue de la Châtaigneraie CS 17608
>> 35576 Cesson Sévigné Cedex
>> 
>> Une école de l'IMT
>> 
>> 
>> 
>>> On 25 Jun 2026, at 18:11, Marc Blanchet <[e-mail]> wrote:
>>> 
>>> 
>>>> Le 25 juin 2026 à 11:52, Alexander PELOV <[e-mail]> a écrit :
>>>> 
>>>> Hi Marc,
>>>> 
>>>> Thank you, this is very helpful!
>>>> 
>>>> For some traffic classes or use cases, there could be a stronger policy at the boundary: reject traffic that does not conform to the constraints of the segment, send an ICMPv6 Destination Unreachable message (Type 1, Code 1) indicating that communication is administratively prohibited, and send a separate ICMPv6-SEC notification providing additional information on how the traffic should be adapted in order to be accepted - for hosts that are able to do so.
>>> 
>>> Maybe. But there is a higher cost of rejecting traffic than to store it. (When storage is full, well, that is another discussion: which obviously means dropping). Because rejecting/dropping because of policies means that you need to signal to the source (either via ICMP which as we know is a bit unreliable, or by normal transport ack means) and to retransmit. In high delay environments, such as deep space, I think one prefers to avoid this (reject because of policy) as much as possible. So to me, this is last resort. I'm more inclined to have local storage and forwarding policies on intermediate nodes (I wrote a draft a while ago for TVR on this), where when storage is full or when forwarding becomes possible again (because link is up), policies would tell what to do with stored packets: forward these ones first, drop these others first, etc... I was thinking more of having those policies within the intermediate node with no signalling, as signalling is on paper good, but with high delays, has its own issues (as described previously)
>>> 
>>>> 
>>>> In that case, the goal would not be to adapt the current transmission quickly, but rather to prevent unsuitable traffic from entering the segment and allow subsequent traffic to conform.
>>> 
>>> Ok. But why not just having those policies at the entrance point. Say: on the last hop before constraint links (or deep space links in general even if the first one is less constraint), one have these policies so "important" traffic is forwarded first, less important traffic is either buffered or dropped if packet too old or buffer full. Then it avoids most issues in space. And one has the fallback as described in the above paragraph.  There were discussions (and I think we put some wording in the arch draft about that) about having proxies at space edge (instead of just IP forwarding devices) where these policies would be handled at transport or application protocol level, which is richer for designing policies (but obviously proxies have their own drawbacks)
>>> 
>>> I'm not saying your proposal is good/bad or else. Just trying to see the different alternatives and what is best.
>>> 
>>>> 
>>>> For the Moon, where the delay is much lower, the same notification could of course be merely advisory - for example, sent at the beginning of a flow - rather than associated with rejection of the traffic.
>>>> 
>>>> In LPWANs we had the problem with DTLS timers. Compression did all the nice work, but default DTLS timers kept expiring frequently.
>>>> Changing some parameters (as allowed by the standard) worked like a charm! But there was no standard way for the LPWAN segment to signal that this needs to be done in order for communication to work correctly.
>>>> 
>>>> Would there be interest in a short presentation and discussion of this work at IETF 126? I think framing the question and hearing the group’s views could be useful.
>>> 
>>> I'll leave this to the chairs.
>>> 
>>> Marc.
>>> 
>>>> 
>>>> Thanks again,
>>>> Alexander
>>>> 
>>>> 
>>>> 
>>>> 
>>>> https://imt-atlantique.webex.com/meet/pelov Alexander PELOV
>>>> Associate Professor
>>>> 02 99 12 24 11
>>>> Technopôle Brest-Iroise CS 83818
>>>> 29238 Brest Cedex 3
>>>> La Chantrerie 4 rue Alfred Kastler BP 20722
>>>> 44307 Nantes Cedex 3
>>>> 2, rue de la Châtaigneraie CS 17608
>>>> 35576 Cesson Sévigné Cedex
>>>> 
>>>> Une école de l'IMT
>>>> 
>>>> 
>>>> 
>>>>> On 25 Jun 2026, at 17:30, Marc Blanchet <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>>> Le 25 juin 2026 à 11:02, Alexander PELOV <[e-mail]> a écrit :
>>>>>> 
>>>>>> Dear TIPTOP WG,
>>>>>> 
>>>>>> A question came to mind while thinking about possible TIPTOP deployments.
>>>>>> It is quite possible that this has already been discussed or addressed somewhere, and that I have simply missed the relevant discussion, so please excuse me if this is the case.
>>>>>> 
>>>>>> When traffic crosses a boundary between network segments with very different constraint regimes (long delays, intermittent connectivity, scheduled contacts) the traffic shaped for one side may be poorly adapted to the other. This may happen because of misconfiguration, but it can also arise on correctly routed paths that simply traverse heterogeneous segments.
>>>>> 
>>>>> Happens "today" in Mars communications. The different bandwidth between Earth-MarsOrbiter and MarsOrbiter-Rover and the contact windows are being handled by JPL (Maros project) and the various missions by very careful planning of all communications, bandwidth usage, etc... and by having the orbiters with storage. JPL people told me that the bottleneck was never the orbiter storage, but low bandwidth of the rover link. 
>>>>> 
>>>>>> 
>>>>>> This raises two questions: should such a boundary be detectable, and should there be a way for the sender or the network to adapt the traffic accordingly?
>>>>>> For example, an endpoint might initially use its default “terrestrial” QUIC parameters, including timers that are unsuitable for the path. If it could learn that the traffic is crossing a segment with very different characteristics, it might be able to adjust those parameters before the connection fails or expires.
>>>>> 
>>>>> In general for deep space further than Moon, the problem with any signalling to the source for "quick" adaptation is that the light speed delay becomes the bottleneck to properly adapt. And if one calculates the BDP or in-flight data, by the time the source receives the signal, the problem has increased a lot; there is a lot of data in-flight. BDP in deep space is your enemy for signalling/adapting (and even more as we are adding more capacity such as high-bandwidth laser links).  For Moon, given ~3sec RTT in a non-intermittent case/period, adaptation based on signalling is very possible. 
>>>>> 
>>>>> This is one reason why I was always pushing hard to have both Moon and Mars within the charter, because a solution for Moon, because of relatively low delay, would not work for further, such as Mars. We likely going to end up with variations of solutions for Moon and Mars, but we would have looked at the whole problem. And most likely, Mars and beyond (Jupiter or ...) are pretty similar. Wes told me about a paper that described the protocol radius: at which radius (say in terms of one-way delay) do the protocol fail or needs adaptations. The radius for Moon and Mars are enough different that they will need different adaptations.  (In a soon to be released new version of drafts, we will reference that protocol radius paper for information).
>>>>> 
>>>>> Sometime ago, I was proposing ECN signalling for Moon case, but did not get a lot of support. One of the reason is that ECN is 1.5RTT (it goes to the destination and back to the source) so it takes longer time than if the intermediate node sends the signal back to the source directly as other proposals such as yours below with ICMP.
>>>>> 
>>>>>> 
>>>>>> Constrained terrestrial links, such as LPWANs, satellite backhaul, and congested or duty-cycled segments, face milder forms of this issue. It seems in some cases deep-space networks may represent the extreme case.
>>>>>> 
>>>>>> I would be interested to hear whether the group considers this a relevant deployment question for TIPTOP, or whether it has already been covered by existing work or discussions.
>>>>> 
>>>>> There were also proposals using SR and some signalling from our Chinese colleagues (was presented a while ago during the deepspace informal meetings). But I've been trying to convince them to write an internet-draft, but no success yet. So can't comment yet until we see the internet-draft.
>>>>> 
>>>>> Marc.
>>>>> 
>>>>>> 
>>>>>> One possible mechanism is explored in the following individual draft, which uses ICMPv6 to communicate information about network-segment constraints:
>>>>>> https://datatracker.ietf.org/doc/draft-pelov-icmpv6-sec
>>>>>> 
>>>>>> This is only one possible approach, and certainly not the only one. My main intention is to raise the underlying question and see whether it would be useful to discuss it within the group.
>>>>>> 
>>>>>> Best regards,
>>>>>> Alexander
>>>>>> -- 
>>>>>> deepspace mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>> 
>>>> 
>>> 
>> 
>