[deepspace] Re: On AQM Re: Review comments on draft-ietf-tiptop-ip-architecture-01 (Sections 4.1, 5.2, 8.2) -- management-plane observability

["Dikshit, Saumya" <[e-mail]>]

Thanks for acknowledging Wes.

Best Regards,
Saumya.

From: Wes Eddy <[e-mail]>
Date: Friday, 14 August 2026 at 10:28 PM
To: Dikshit, Saumya <[e-mail]>
Cc: Dikshit, Saumya <saumya.dikshit=[e-mail]>; Marc Blanchet <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Tony Li <[e-mail]>; Srivastava, Mukul <[e-mail]>
Subject: Re: On AQM Re: Review comments on draft-ietf-tiptop-ip-architecture-01 (Sections 4.1, 5.2, 8.2) -- management-plane observability

Those changes seem okay to me, thanks.

On Fri, Aug 14, 2026 at 12:10 PM Dikshit, Saumya <[e-mail]<mailto:[e-mail]>> wrote:
Hi Marc,

Thanks for sharing the SNMP draft (reviewing it)

On AQM side of the split thread, if we can go for a text in Section 4.1:

This might be implemented as a deep queue with a configured bound and a drop policy. This is not active queue management in the RFC 7567 control-loop sense: the queue is intentionally long-lived, and congestion feedback to endpoints is not expected to be actionable within a useful interval at these delays. Drop decisions are therefore based on local policy, for example packet age and traffic class.

If useful, companion line for Section 8.2:

The forwarder SHOULD expose the queue state used by that policy, including current and high-water occupancy, oldest-packet age, and drop counters attributed to the policy dimension that triggered each drop.

Thanks,
Saumya

This avoids repeating debate and moves straight to mergeable wording.
From: Dikshit, Saumya <saumya.dikshit=[e-mail]<mailto:[e-mail]>>
Date: Monday, 3 August 2026 at 5:51 PM
To: Marc Blanchet <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Wesley Eddy <[e-mail]<mailto:[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>; Srivastava, Mukul <[e-mail]<mailto:[e-mail]>>
Subject: [deepspace] Re: On AQM Re: Review comments on draft-ietf-tiptop-ip-architecture-01 (Sections 4.1, 5.2, 8.2) -- management-plane observability

Dear Marc,

Inline below with tag [SD]

   This might be implemented as a deep queue with a configured bound and a drop policy.
   Note that this is not active queue management in the sense of [RFC7567]: the queue is
   intentionally long-lived, and the congestion signal that AQM relies upon cannot be
   acted upon by the endpoints within a useful time. The drop policy is therefore chosen
   on other criteria, such as the age of the packet or its traffic class.

Saumya.


> Actually, AQM does not require any network signalling, it is first various algorithms
> locally applied to queues in forwarders.

<SD>

It is local to the forwarder, and no explicit marking need be enabled, and that part of my earlier note was aimed inaccurately.

On the word signalling, Section 1.2 introduces the term as

   "a class of technologies that, by signaling to common congestion-controlled transports
    such as TCP, manages the size of queues"

with the drop itself as the signal:

   "The detection of loss also provides a signal to a reliable transport (e.g., TCP,
    SCTP) that there is incipient congestion, using a pragmatic but ambiguous heuristic."

So the signaling is implicit rather than absent, and the question is not whether packets. are marked,
but whether anything at the far end can act on the signal within a useful time. In deep space it cannot:

  *
the sender learns of the drop one round trip later, and by then the condition has usually changed.
  *
The document also states that it is essential that all Internet hosts respond to loss.

</SD>

> Re-reading carefully RFC7567 tells me that it does not require signalling, but suggests
> (SHOULD) it. It also discusses buffer bloat which is not applicable in deep space, as
> is at least.

<SD>

I agree, Bufferbloat does not carry over, and the reason it does not is the same reason the recommendations do
not. Section 1.1:

   "It is important to reduce the steady-state queue size, and this is perhaps the most
    important goal for queue management."

and

   "Queues that are normally small are preferred in network devices"

Section 4.1 describes a queue that is intentionally large and long-lived, holding traffic across a scheduled outage.
The most important goal of the cited document is the opposite of the behaviour the architecture requires.
The purpose of the buffer differs too:

   "The goal of buffering in the network is to absorb data bursts and to transmit them
    during the (hopefully) ensuing bursts of silence."

Here the egress rate is zero.
That is an outage, not congestion, and the two are indistinguishable to any algorithm that infers load from occupancy or from delay.

</SD>

> AQM is used today everywhere without the actual use of ECN or L4S or ... So it stands
> by itself in deepspace.

<SD>

The deployment fact is not in question. Where I would not follow "stands by itself" is
what an implementer then builds. The delay-keyed algorithms in this family drop once the
time a packet has spent in the queue exceeds a target for longer than an interval. In a
store-and-forward buffer during a link outage that time is hours by design.

So a reader who takes "a deep queue with active queue management (AQM) [RFC7567]" and
applies it faithfully drains precisely the traffic the architecture exists to preserve,
and does so most aggressively while the link is down. RFC 7567 is BCP 197, so a reader is
entitled to treat the pointer as guidance to follow rather than as background.

</SD>

> So yes parts of RFC7567 are relevant, some are not. But the whole point here is to give
> a reference of what is AQM for the reader. I haven't found a better (still recent)
> document. I'm not sure why we really need to remove RFC7567.

<SD>

I am with you that, RFC 7567 is still the best recent document for telling a reader what AQM is, and if we drop it the term in 4.1 has no reference at all.

So keep the citation. Use it as shown in the text at the top of this message/ The reader still gets the definition, the reference stays..
If It also fits pull request 57: packet age is one of the four observables there, so the buffer state feeds the drop policy directly.

</SD>

Thanks,
Saumya

From: Marc Blanchet <[e-mail]<mailto:[e-mail]>>
Date: Sunday, 2 August 2026 at 11:50 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Wesley Eddy <[e-mail]<mailto:[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>; Srivastava, Mukul Kumar <[e-mail]<mailto:[e-mail]>>
Subject: On AQM Re: Review comments on draft-ietf-tiptop-ip-architecture-01 (Sections 4.1, 5.2, 8.2) -- management-plane observability

Hello,
Breaking the thread on each topic to make this discussion more manageable. Below AQM.

Marc.


> Le 31 juill. 2026 à 09:56, Dikshit, Saumya <[e-mail]<mailto:[e-mail]>> a écrit :
>
>
> Dear Marc,
>
> Thank you for acknowledging, analyzing my comments, and opening the issues as tracker.
> Please see my issue-wise response.
>
> Issue 54: SNMPv2 vs SNMPv3
> -------------------------------------
>
...
<MB>responded in another email</MB>

>
> Issue 55: AQM reference misleading
> -----------------------------------------------
>
> One detail on the fix:
>
>     • Dropping the reference on its own leaves "a deep queue with
>       active queue management (AQM)" in 4.1 uncited, and it is the
>       term rather than the pointer that misleads.
>      I would suggest the phrase goes with it, along the lines of
>       "a deep queue with a configured bound and drop policy",
>     which is what the rest of 4.1 goes on to describe.
>
>     •    That also retires the RFC 7567 entry from the reference list.

<MB>

Actually, AQM does not require any network signalling, it is first various algorithms locally applied to queues in forwarders.
Re-reading carefully RFC7567 tells me that it does not require signalling, but suggests (SHOULD) it. It also discusses buffer bloat which is not applicable in deep space, as is at least.
AQM is used today everywhere without the actual use of ECN or L4S or ... So it stands by itself in deepspace.
So yes parts of RFC7567 are relevant, some are not. But the whole point here is to give a reference of what is AQM for the reader. I haven't found a better (still recent) document.
I'm not sure why we really need to remove RFC7567.

Marc.

PS. Not written by AI. Expect bad English.
</MB>


>
>
> Issue 56: forwarder buffer state observable
> -------------------------------------------------------
>
>     •    I will send the Section 8.2 paragraph as a pull request rather
>       than as list mail, keeping it to the four items from my earlier
>       note.
>
>     •    One structural point comes with it. Section 4.1 has no anchor at
>       present, so 8.2 cannot cross-reference it; the pull request adds
>       one.
>
>     •    I will draft the generic text for the use case draft as well.
>       Please point me at the right place for it.
>
>
> Comment 4: Section 5.2, PCEP liveness
> ----------------------------------------------------
>
>     • PCEP maintains session liveness through its Keepalive timer and
>       DeadTimer, so the PCE has to sit within a low-delay domain and
>       PCEP must not traverse the deep-space link.
>
>     •    That is a deployment constraint rather than an implementation
>       detail, and 5.2 should record it in one sentence.
>
>
> Comment 5: Section 5.2, reachability semantics
> --------------------------------------------------------------------
>
>     •    The three reachability states cannot be distinguished by
>       probing, since 5.2 rules that out, so the distinction has to come
>       from the contact plan together with node-local state.
>
>     •    That makes it the same underlying gap as issue 56, and I would
>       suggest the two be handled together rather than tracked
>       separately.
>
>
> Happy to take any of these to the issues if that is easier than the
> list.
>
> Thanks again.
> Saumya
>
> From: Marc Blanchet <[e-mail]<mailto:[e-mail]>>
> Date: Thursday, 30 July 2026 at 8:47 PM
> To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Wesley Eddy <[e-mail]<mailto:[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>; Srivastava, Mukul <[e-mail]<mailto:[e-mail]>>
> Subject: Re: Review comments on draft-ietf-tiptop-ip-architecture-01 (Sections 4.1, 5.2, 8.2) -- management-plane observability
>
>
> > Le 30 juill. 2026 à 08:45, Dikshit, Saumya <[e-mail]<mailto:[e-mail]>> a écrit :
> >
> >
> > Hello Authors of draft-ietf-tiptop-ip-architecture, WG members,
> >
> > I read the draft and concluded that the decision to keep BP/DTN out and to frame store-and-forward as an IP-forwarding buffering behaviour (Section 4.1) makes the architecture much easier to reason than otherwise.
> >
> > My background is network management and OAM rather than space systems,  so my comments cluster around the management plane and around observability of the mechanisms the document already specifies.
> > Please find 5 comments below, roughly in decreasing order of substance.
>
> Thanks for your review! Really appreciated.
>
> My comments enclosed in <MB></MB> below.
>
> > Comment 1 is the one I would most like a WG view on.
> >
> > 1. Section 8.2: the SNMP statement does not hold for SNMPv3
> > ---------------------------------------------------------------------
> >
> > The current text reads:
> >
> >    "While being declared historic in IETF, SNMP[RFC1157] runs over UDP
> >     and has no notion of time.  Therefore, with proper configuration of
> >     client timeout, it can be used as is to manage nodes and services
> >     in deep space."
> >
> > I believe this is accurate only for SNMPv1 and SNMPv2c.
>
> <MB>As written, it states RFC1157, so it is not implying SNMPv3. FYI, tests were done using SNMPv2c. So I think the text is correct as is. </MB>
>
> > It is not accurate for SNMPv3, which is the only version with usable security.
> >
> > The User-based Security Model (USM, RFC 3414) explicitly does have a
> > notion of time. Every authenticated message carries
> > msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime. RFC 3414
> > Section 2.2.3 fixes the Time Window at 150 seconds for all users, and
> > Section 3.2 requires the receiver to reject a message with
> > notInTimeWindow when msgAuthoritativeEngineTime is more than 150
> > seconds behind the receiver's local notion of snmpEngineTime. This is
> > a replay-protection mechanism, and unlike a client timeout it is not a
> > tunable deployment parameter.
> >
> > A 150-second window cannot accommodate an Earth-Mars one-way delay of
> > 4-24 minutes as described in Section 1. An authenticated SNMPv3
> > exchange across such a link would fail time-window validation in
> > essentially every case, independent of client timeout configuration.
> >
> > This also interacts with Section 10, which already notes that "given
> > possible lower frequency of time synchronization, clock drifts may
> > affect expiration and validation" -- USM is a concrete instance of
> > exactly that problem.
> >
> > Suggested resolution: either scope the sentence explicitly to SNMPv1/
> > v2c
>
> <MB>Again, this is already the case.<MB>
>
> > and state the security consequence of doing so,
>
> <MB>I'd suggest to refer to RFC1352 section 2 for description of the threats. I don't think it is appropriate to start discussing security issues of an old protocol in this document.</MB>
>
> > or add a sentence
> > acknowledging that SNMPv3 USM time-window validation is incompatible
> > with deep-space delays and that this is an open item. I would be happy
> > to supply text for either.
>
> <MB>then SNMPv3 may need a profile for deep space if there is interest in doing so.
>
> Given that the direction is towards Netconf/Yang, I'm not sure we want to spend too much time in the document about SNMP (whatever version).
>
> So I would agree to your first option by adding a reference to RFC1352 section 2 to point the reader to the security issues of the old SNMP versions.
>
> I filled a GitHub issue for that purpose: https://github.com/marcblanchet/draft-tiptop-ip-architecture/issues/54
>
> Then if someone wants to write a profile of SNMPv3 for deep space, then please do so in a separate document.
>
> </MB>
>
> >
> >
> > 2. Section 4.1: AQM's control-loop assumption does not hold here
> > ---------------------------------------------------------------------
> >
> > Section 4.1 suggests the deep buffer "might be implemented as a deep
> > queue with active queue management (AQM) [RFC7567]".
> >
> > AQM as defined in RFC 7567 works by dropping or marking early in order
> > to signal congestion to responsive end-to-end congestion control, on
> > the assumption that the sender reacts within roughly one RTT. In this
> > environment the sender's reaction arrives one or more RTTs later --
> > potentially hours -- by which time the buffer occupancy that triggered
> > the signal is unrelated to current conditions. The feedback loop AQM
> > depends on is not merely slow here; it is decoupled from the state it
> > is meant to regulate.
> >
> > What Section 4.1 actually goes on to describe -- a bounded buffer plus
> > a configured drop policy keyed on traffic class, addresses, or flow
> > label -- is an admission and drop policy evaluated against the contact
> > plan, not AQM in the RFC 7567 sense.
> >
> > Suggested resolution: either drop the AQM reference,or keep it with an
> > explicit note that it is being invoked only as a buffer-bound and
> > drop-policy mechanism and that its congestion-signalling function is
> > not expected to be effective at these delays. The current phrasing may
> > lead implementers to enable a terrestrial AQM algorithm and expect it
> > to behave sensibly.
>
> <MB>You are right that it may imply terrestrial behaviours. So I agree with you to just drop the reference.
>
> https://github.com/marcblanchet/draft-tiptop-ip-architecture/issues/55
>
> </MB>
>
> >
> > ---------------------------------------------------------------------
> > 3. Sections 4.1 and 10: buffer state is required but unobservable
> > ---------------------------------------------------------------------
> >
> > Section 4.1 requires "proper provisioning of buffer storage memory for
> > the target deployment and usage" and defines a policy-driven drop
> > behaviour when the buffer is full. Section 10 separately identifies
> > that "an attacker could generate traffic to exhaust buffers at
> > intermediate nodes".
> >
> > Both of these depend on the operator being able to see buffer state,
> > but the document does not describe any operational state or telemetry
> > for the deep queue.
>
> <MB>There were some work about this but nothing has been put in text.</MB>
>
> > Without it, the provisioning requirement in
> > Section 4.1 cannot be validated after deployment, and the attack in
> > Section 10 cannot be distinguished from legitimate congestion or from
> > a longer-than-usual scheduled outage.
> >
> > Suggested resolution: a short paragraph in Section 8.2 identifying the
> > minimum operational state a TIPTOP forwarder should expose. In our
> > view that is at least:
> >
> >    *  current and high-water buffer occupancy, per queue;
> >    *  age of the oldest buffered packet (how stale the queue head is);
> >    *  drop counters attributed to the policy dimension that caused the
> >       drop (traffic class, prefix, flow label), so that the configured
> >       policy in Section 4.1 is auditable;
> >    *  an explicit event when a buffer is cleared other than by
> >       transmission, e.g. the reboot and memory-upset cases already
> >       named at the end of Section 4.1.
> >
> > The last item matters because those losses are silent to the endpoints
> > until a transport timeout fires, which at these delays is a very long
> > time.
>
> <MB>Agree that the current text is light. I opened an issue about this.
>
> https://github.com/marcblanchet/draft-tiptop-ip-architecture/issues/56
>
> Happy to receive contribution!
>
> We(wg) may want to also state something about this in the usecase draft, in a generic way.
>
> </MB>
>
>
> >
> > ---------------------------------------------------------------------
> > 4. Section 5.2: PCEP has the liveness property the section rejects
> > ---------------------------------------------------------------------
> >
> > Section 5.2 correctly rejects routing protocols that "require proof of
> > liveness between protocol partners, implemented through the periodic
> > exchange of packets", and then recommends a controller-based approach
> > citing PCE (RFC 4655).
> >
> > PCEP itself (RFC 5440, Section 4.2.2) maintains session liveness
> > between PCC and PCE using a Keepalive timer and a DeadTimer, so if PCEP
> > were to run across a long-delay or intermittent link it would exhibit
> > the same problem the section just ruled out.
> >
> > I assume the intent is that the PCE is reachable within a low-delay
> > domain -- for example co-located on the celestial body it serves --
> > and that PCEP never traverses the deep-space link. Section 5.2 does
> > not say this, and I think it is worth one sentence, because it is a
> > significant deployment constraint rather than an implementation
> > detail.
>
> <MB>I let my co-authors to comment on this</MB>
>
> >
> > ---------------------------------------------------------------------
> > 5. Section 5.2: reachability semantics are left undefined
> > ---------------------------------------------------------------------
> >
> > "Optimal routing for domains with intermittent links is out of scope
> > for this document" is a reasonable scoping decision. However, the
> > document does not say how an operator or an application is meant to
> > distinguish three states that are operationally very different:
> >
> >    *  destination reachable, packets being buffered for a scheduled
> >       window, delivery expected;
> >    *  destination unreachable because a scheduled window was missed;
> >    *  destination unreachable because of an actual fault.
> >
> > In terrestrial networks these are separated by active probing, which
> > Section 5.2's own reasoning rules out. This is the gap that motivated
> > draft-dikshit-tiptop-oam-considerations, mentioned in comment 6.
> >
>
> <MB>I let my co-authors to comment on this</MB>
>
> >
> > Our Related work
> > ----------------------
> >
> > Comments 3 and 5 are developed further in draft-dikshit-tiptop-oam-considerations,.
>
> <MB>will review</MB>
>
>
> >  The draft cites Section 8.2 explicitly and scopes its contribution to the fault and performance dimensions of OAM,  with a new Section 4.5 describing where the two documents meet:
> >     • shared contact-window scheduling for management and OAM traffic,  explicit staleness annotation on retrieved operational data rather than timeout extension alone,
> >     • and contact-window-aware buffering and replay of YANG notification subscriptions (RFC 8639 / RFC 8641),
> > which Section 8.2 does not currently discuss.
> >
> > We are not asking for that document to be adopted at this stage.
> > If the WG would rather see this material folded directly into Section 8.2 of the architecture document than carried separately, we are more than happy to provide text.
>
> <MB>thanks for your review and great comments!
>
> Marc.
>
> PS. Not written by an AI agent. Bad English is likely.
> </MB>
>
> > Best regards,
> > Saumya Dikshit
> > Aruba Networks, Hewlett Packard Enterprise
> > [e-mail]<mailto:[e-mail]>
> >
> > (with Mukul Srivastava, HPE)
>