Re: [Deepspace] [dtn] technical remarks
Jorge Amodio <jmamodio@gmail.com> Mon, 25 September 2023 21:23 UTC
Return-Path: <jmamodio@gmail.com>
X-Original-To: deepspace@ietfa.amsl.com
Delivered-To: deepspace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197CBC15108B; Mon, 25 Sep 2023 14:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.102
X-Spam-Level:
X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCSXw6Zyv9c6; Mon, 25 Sep 2023 14:23:20 -0700 (PDT)
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7C4C14CEE3; Mon, 25 Sep 2023 14:23:14 -0700 (PDT)
Received: by mail-vs1-xe2e.google.com with SMTP id ada2fe7eead31-452c0d60616so4669792137.1; Mon, 25 Sep 2023 14:23:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695676993; x=1696281793; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KtN/PpdIostzclrSuRlXD+8bXwweQQjP7ybMMiqRtl4=; b=SoFsz1AGg5Jh57JYa5nFm6KuAt0wWDJY7lH8KRnuaIuOmiBijK8OBlbHnloa8EW5D/ wMY3aUNfH5T7Wf4NJDfQcDi4/YZX7Tch6P6g9NxnGpc2PpqE+kA0umDXT493AFs1wcYW mDoAe8otLOZPFqzJGdupEpxzASRkn+A5M/LtGP7b9vqgrW6fycXPnDTpTksyntXxijlb 8hkxA5GqlsSRg6Enl4O4Wr1PJo7ZoxojeOCyhzxNOPAYqNK8uUBgORsfSiwhvQ0dJyms TedfwrmvRLhriTUVACm3DGd9MfmQDNCEafclYbRBLt5SCpv1WzfdZeulT1v+n8MZtCZb Ci3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695676993; x=1696281793; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KtN/PpdIostzclrSuRlXD+8bXwweQQjP7ybMMiqRtl4=; b=C19m8eEhnQAguJ3eiGAH96/SsXuGJ+3mdQ5oWUI9L77naS8H+MQ+i9z4NRApPNgO81 hhvP5KMUpfCe12u6O1r4p8f03boQfKdVWxj9URcDZRYubC7fSy1XjK1re2fM5SUcj3/R kZc31Nx5t594KEcNRtT7Ze5lRl/Ny+DA3bYb06+4jZwExhH75ITOu+6vcHrcLqesLEP2 FC5pYYowkBwv3saA0vPkpiWtrZBCLMc0kSlZx7No6HcUDBLy20LMTezb4Y1p7DvqvUgi UwBQxyaAzr4mZMDSlIdE3m+qB5a2qxk2NnALYjvdrNpnYo4w8UPqw9elErCymoiqenDz /g3g==
X-Gm-Message-State: AOJu0YyYFuWSaTzSykDgT5sO/s+xRWlD1sCd8NMfSokNl/l3R8VHCoLj NvlaymfjX14CDf5EpiQ2Q8ol55SNf/h5+2u95JSKsURHSwM=
X-Google-Smtp-Source: AGHT+IE9Ap0IDjZTsNRuoNVsuc4iHFrBoJ+DcCvaOtFAUgvKyN4UDzaYd/5WL42Y3ETmidCzRFTCJ4Tj5rbsRPkXIek=
X-Received: by 2002:a05:6102:5590:b0:450:fc9b:552e with SMTP id dc16-20020a056102559000b00450fc9b552emr487513vsb.1.1695676993410; Mon, 25 Sep 2023 14:23:13 -0700 (PDT)
MIME-Version: 1.0
References: <050001d9ea91$d25d55f0$771801d0$@gmail.com> <E127BE58-D0D4-4692-9D19-5E99CA5DA7B5@viagenie.ca> <04a401d9edd3$08c6d0f0$1a5472d0$@gmail.com> <F7B5CEEC-4A89-4F4C-A351-59A6735146E7@viagenie.ca> <D1A7B956-7766-4A16-9AC6-A5FC6ECC6B23@gmail.com>
In-Reply-To: <D1A7B956-7766-4A16-9AC6-A5FC6ECC6B23@gmail.com>
From: Jorge Amodio <jmamodio@gmail.com>
Date: Mon, 25 Sep 2023 16:22:37 -0500
Message-ID: <CAMzo+1b2q+ntep3tny+o0a6qRziiZQLxKi3Y65=ROv=SCdV2Fw@mail.gmail.com>
To: Dean Bogdanovic <ivandean@gmail.com>
Cc: Marc Blanchet <marc.blanchet@viagenie.ca>, Scott Burleigh <sburleig.sb@gmail.com>, deepspace@ietf.org, DTN WG <dtn@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d8990b06063590b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/deepspace/HLP9cEr5YFyXDsmT6dTRfto3i6E>
Subject: Re: [Deepspace] [dtn] technical remarks
X-BeenThere: deepspace@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IP protocol stack in deep space <deepspace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/deepspace>, <mailto:deepspace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/deepspace/>
List-Post: <mailto:deepspace@ietf.org>
List-Help: <mailto:deepspace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/deepspace>, <mailto:deepspace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Sep 2023 21:23:24 -0000
That is one of the reasons for LTP existance. -J On Mon, Sep 25, 2023 at 4:15 PM Dean Bogdanovic <ivandean@gmail.com> wrote: > IP stack has been designed with no timers in mind from very early days. > The protocol is called UDP. There is no requirement that UDP datagrams be > delivered in finite time at all. In other words, it is perfectly acceptable > never to deliver a UDP datagram. > > My main hypothesis: > Network doesn’t have to guarantee packet delivery, let the application > decide what has to be delivered. > > For deep space communication, we have to take an application level view of > the connectivity, let the application decide about data transmission and > the underlying network delivers the data. The network doesn’t know if data > that arrived or is missing is important. TCP takes the presumption it is, > UDP the opposite. > > I can see a scenario where the applications sends all the time limits to > the routers in space how long to keep the data in the local storage, Using > QUIC and HTTP/3, the connection is established once and after that there is > 0 delay to send the data to its destination. No new handshake is needed. > You don’t need keep alive packets. The application on both sides decides > for how long it wants to keep listening to it. Even if the packets come > after the application has decided to discard all the data, this can be > communicated through the deep space network, so each node can drop that > type of packet. > > We need to figure out a new application design and network management > paradigm that is impacted by long delays. > > Different applications can define different behavior from the network and > communicating that information is easier to be done with existing > frameworks, than inventing something new ones. > > Dean > > On 25 Sep 2023, at 13:31, Marc Blanchet wrote: > > > > Le 23 sept. 2023 à 06:04, sburleig.sb@gmail.com a écrit : > > Well, maybe I am so out of touch with modern Internet standards that I > don’t realize how delay-tolerant the architecture is nowadays. Here are > some of my possibly misplaced concerns. > > The “late binding” concept built into the BP suite is based on the idea > that connectivity lapses between nodes on an end-to-end path may be so > lengthy (hours certainly; days for some deep space missions) that the > destination node may change its location – its IP address – while traffic > is en route to its earlier address. Will this simply not happen frequently > enough to justify late binding measures? If so, can you explain why? If > not, how will Internet architecture handle these anomalies? > > > The fact that a node changes location does not mean changing its IP > address. QUIC has the IP address and/or port change managed securely. The > peers confirm their new IP address/port change by a crypto change, since > they already have established a trust relationship in the first handshake. > So it is robust to DOS or man-in-the-middle attacks and it works with IP > address/port change. > > > A related point: will DNS be used across the solar system to resolve > destination names to IP addresses? If so, will DNS lookup queries traverse > interplanetary links > > > Should not. > > or will they be resolved by local DNS servers? > > > yes. > > If the latter, will DNS information be synchronized across the solar > system by zone transfers or something similar? > > > The ones you need. > > In either case, are we confident that the volume of DNS synchronization > traffic across the interplanetary network will be so low as not to > significantly degrade science traffic? > > > As answered to Keith in another email, there is a draft on DNS deployment > which is already written and currently reviewed by DNS experts. I’m > awaiting a few more reviews and will publish. Up to now, no reviewer got > heartburn. > > > If a packet arrives at a router from which there is currently no onward > connectivity, it will be retained in storage until the next onward > connection is established, correct? > > > yes. > > Suppose that next onward connection is never established (maybe because > the next router in the path has been destroyed by a meteor impact). The > packet is not forwarded, so its hop count does not increase, so its hop > limit is never exceeded; would it continue to occupy storage at the router > indefinitely? If not, what is the pure IP functionality that would cause > it to be discarded? > > > This is a forwarding policy/AQM discipline. It is already implemented but > again might need to be tuned by increasing timers. > > > I mentioned in an earlier email my misgivings about the ability of QUIC to > impose flow control and congestion control over round-trip times that may > be measured in hours or (if exercised only at the source and destination) > days. I think those are still open questions. > > > > Are QUIC retransmission timeout intervals going to be learned over time by > measuring the interval between transmission and acknowledgment of several > packets, or are they going to be provided by management (e.g., known > one-way light time as determined from orbital elements)? If the former, > won’t it take a long time to figure out the correct timeout interval for > retransmissions if the round-trip times are measured in hours? If the > latter, is that capability already defined in the QUIC specification? And > does it include automatic adjustment of the timeout interval when the end > of a period of bidirectional connectivity is reached? > > > The automatic securing of QUIC connections by TLS is terrific, but it is > only in effect while the packet is in transit, correct? That is, once the > packet has reached its destination it is no longer protected? > > > Well, it is decrypted by the QUIC stack at the destination and then pushed > to the application. Like TLS today. I’m not sure I get your point here. > > This is fine if the QUIC destination is the packet’s final destination, > but in that case the packet retransmission timeout interval at the source > becomes hard to compute: the packet may reside in storage at one or more > routers along the path for various periods of time, which can only be > determined if the entire path to the destination (not just the next-hop > router) is known at the moment the packet is sourced. > > > I’m not parsing you here, specially: "the QUIC destination is the packet’s > final destination »: it is always the case, unless you do some proxies. And > even that, the last leg of the last proxy will be the packet’s final > destination. So I’m not sure. > > If, on the other hand, transmission along the path is accomplished by a > string of QUIC proxies as suggested in the deepspace-ip-assessment draft, > > > Actually, the string of QUIC proxies was discussed but not recommended. > I’ll look again at the text. It may be useful in some deployment scenarios, > but we don’t need it. > > then the packet will be delivered by QUIC multiple times while traversing > the path. In this case it might be resident at multiple routers while > awaiting onward connections and, while resident, would not be protected by > QUIC/TLS. Does this mean that additional application-layer security is > always going to be needed for all deep space IP traffic? > > (A note on your remarks regarding LTP: you say that “to get its benefits, > one has to make sure that all links are using LTP.” That is simply false. > Every hop on a BP end-to-end path can use a completely different > convergence-layer protocol. The ability to exploit – and/or adapt to – the > different characteristics of different types of links on the end-to-end > path, instead of expecting a single set of communication properties to hold > everywhere along the route, is one of the advantages of the BP > architecture.) > > > Sorry, I should have rephrased as: every link should have a reliable > transport under BP to achieve an end to end reliability. > > > I understand that HTTP itself can be operated in a RESTful manner, so that > it is no longer a client/server protocol – very helpful! > > > Well, it is a client-server protocol. RESTFul does not change anything > about that. > > What about HTTPS? Will HTTP always be run over QUIC, so that it is always > automatically secured by TLS? Or will TLS handshakes be necessary when > establishing a HTTPS session? > > > See QUIC (RFC9000, RFC9001,…). QUIC includes TLS and TLS is negotiated > together with QUiC parameters in a single RTT. QUIC can’t run without TLS. > > > I understand too that, thanks to zero-RT, only connection to a new or > re-located peer (new IP address) or to a socket with a different port > number would force a QUIC connection handshake, resulting in a > communication hiatus of no more than 40 minutes at Mars, assuming no data > loss. You are certainly correct that new spacecraft are not likely to be > added to the network very often, but of course not all nodes of the space > network are going to be spacecraft – ground nodes are going to be included > in the network as well, right? Those are likely to cost closer to $2000 > than $100,000,000, so there could be a good many of them, with new ones > added frequently. Also, wouldn’t applications running on spacecraft open > new sockets relatively often? > > > A QUIC connection can be established between 2 peers for an almost > infinite amount of time, say for 2 years if you want. A QUIC connection > enables multiple streams (connections/sockets in the traditional TCP/UDP > sense) to be carried over that « pipe ». So one can have multiple > applications, using HTTP or anything, still carried over a single > connection between 2 peers. > > > How would files be transferred over deep space IP? Would we use FTP and > SFTP and TFTP as in the Internet? If so, don’t we pay for a connection > handshake (1 to 3 round trips of up to 40 minutes each for FTP, more for > SFTP) whenever starting a session, plus a query/response round trip for > each file? If not, what will we use instead? > > > File transfer can be done in a myriad of ways. Nowadays, if you transfer a > file over Internet, it is ~98% over HTTP. > > > Establishing an SSH session requires a multi-round-trip handshake, but > maybe we won’t need SSH in the deep space Internet? > > > SSH is an example of an interactive application protocol not well suited > for space use. As you know, SSH, like Telnet, sends each keystroke in a > single packet. I’m pretty sure no one was planning to have that kind of > application over BP, because it does not make sense. So don’t use SSH as > is. However, one can configure SSH to send the line in a single packet (aka > after the CR/LF). That would be more possible, again like any application > protocol, if you configure the timeout properly. In a line mode, it would > be similar to Command and Control currently used. > > Will we just use RESTCONF instead? > > > That is one possibility yes. > > Does RESTCONF let you do everything you’d otherwise do with SSH? > > > RESTCONF can be more compared to DTNMA. So BP will be managed by DTNMA, IP > will be managed by RESTCONF. > > > I think we’re going to want to send email over this network. > > > Great! > > Do I understand correctly that SMTP, POP3, and IMAP require connections, > and POP3 and IMAP servers deliver mail only in response to queries, all of > which require round-trip exchanges? > > > This is more a deployment discussion than the actual protocol. But I > remember that we did not discuss it in the draft, so I guess we should add > it. In a nutshell, the deep space links are just one link. SMTP can be > carried over and then mail sits in the mail server on the celestial body > network infrastructure. The user then just use regular IMAP (or even > web-based mail) locally on the celestial body. > > > How about RTP, DHCP, NTP? Will their session establishment procedures > work over interplanetary signal propagation delays? > > > Good questions. As the draft says, there is a need to assess various > application protocols to see which one: works as is, works with an > adjustable timer, does not work, needs a protocol change, … From your list: > - RTP: I was surprised to see that space agencies in CCSDS have > standardized RTP over BP. So I guess if RTP works over BP, it shall work > over IP, but I haven’t looked at it. Cisco and Lockheed Martin have made a > presentation on 2-way videoconferencing in space a few IETFs ago. One > should look at it. > - DHCP: I see no use for DHCP over deep space links. Could you tell me why > you need it? > - NTP: interesting question. On celestial body networks, no issue. Over > deep space link, don’t know. Question is do we need it. How is time sync > done in BP? > > > I’d also be worried about the routing protocols – RIP, OSPF, BGP. If > routing in the deep space IP network is going to rely on current > information about the topology, as in the Internet, won’t we see a lot of > routing errors due to lengthy delays in the arrival of new information > about discovered topology changes? > > > Yes. Again, TVR wg is looking at this problem. And this is written in the > draft. > > > There are probably a few other issues I would need to understand better, > but this is all I can think of for now. > > > Thanks for taking the time to review the draft. Hope I answer your > questions. > > Regards, Marc. > > > > Scott > > > > *From:* Marc Blanchet <marc.blanchet@viagenie.ca> > *Sent:* Tuesday, September 19, 2023 11:29 AM > *To:* Scott Burleigh <sburleig.sb@gmail.com> > *Cc:* deepspace@ietf.org; DTN WG <dtn@ietf.org> > *Subject:* Re: [dtn] technical remarks > > > > Le 18 sept. 2023 à 20:39, sburleig.sb@gmail.com a écrit : > > Hi, Marc. > > > Well, I’ve been pushing that idea. The actual draft has 2 co-authors. So I > guess this should be discussed in general, not targeted to me specifically. > > > To get this started, here are some remarks on the new draft from a > generally technical perspective. > > > Thanks for your great review. Very appreciated. > > > > In my mind, the central conceptual premise of RFC 4838 and the DTN work > that grew out of it is that communication round trips must be rigorously > excluded from the communication protocols used to operate an internet over > interplanetary links. This is because long signal propagation latencies > and potentially frequent and lengthy lapses in connectivity between nodes > may make round-trip times so long that the information received on the > return path is obsolete or otherwise no longer usable and/or arrived so > late that opportunities for further transmission had to be foregone - in > all cases, an unacceptable waste of expensive communication resources. > > > Right. Deep space has specific characteristics (long delays, > interruptions) that some applications/protocols/… are not designed for that > use case, whatever we use IP or BP. > > > > That concept was (I believe) the rationale for moving beyond the IP stack > in advocating for a solar system internet: virtually every important > protocol in the IP stack (IP itself being the main exception) required a > handshake to negotiate communication parameters, issued data from a server > in response to a query from a client, or both. > > > We start to disagree. Yes, there are some application protocols (or some > applications) that were designed with the use of instant negotiations and > handshakes. That does not preclude them to be unusable in a less > « friendly » environment. It depends. Our initial findings is that it is > not that quite bad, on the contrary. An example. While not all applications > we are using on Internet make sense in deep space (this is an important > point), a very large majority is using HTTP as its « application > transport ». HTTP does not have a notion of time by itself, unless one is > using some specific headers (see the draft for details), in which one > should be careful about the values you put in; consequence is no change in > HTTP needed. And HTTP is used a lot, a lot, in current applications with > the RESTful paradigm, or other variations/enhancements such as gRPC, …. I > verified it: it works just fine as is, if you are changing default timers > in configs of clients and servers. No change in code, no change in > protocol, no change in software. Many/Most? Internet applications we are > using today are not well designed for deep space use case: of course, you > won’t buy a Taylor Swift ticket over a deep space link (at least for now > ;-). But, if one is developing an application for a relevant use in space, > then HTTP is able to carry your application no issue. That is a big big win > for getting any current developer to develop space applications, reusing > many frameworks in use today. Of course, they need a few best current > practice (some are already in the draft, but obviously not comprehensive) > to be careful to use, for example, a completely asynchronous design (which > is in fact the BCP even for Internet applications) and be careful about > timers. That is mostly it. > > To summarize, while there are some application protocols that are not > suited for space use case, we have a great framework nowadays that do work > well in this environment with simple but careful config. > > > > The keystone of your draft seems to me to be the substitution of QUIC for > TCP. > > > Yes, it is an important part of it. But as you have read the draft, we > looked at the different levels of the protocol stack to make sure it > overall works. Looking into only one piece would not work. > > > QUIC in itself seems to me quite cool: QUIC clearly accelerates connection > establishment and solves TCP's head-of-line blocking problem. In the BP > world, I think QUIC would make an outstanding convergence-layer protocol. > > > When you say QUIC CLA, you mean BP over QUIC over IP. Yes, it could be > defined and it would work. The current design for deep space comm is to use > BP over LTP over space links. So I guess the QUIC CLA will be used in > terrestrial networks (or celestial body local networks) as a replacement of > the TCP CLA. Fine, but that is not the proposal in the draft. To me, while > possibly better, replacing the TCP CLA with a QUIC CLA for terrestrial > networks is IMHO a marginal advantage, as many of the TCP CLA used today is > between space agencies private high-speed networks. I would welcome the dtn > wg to look at the QUIC CLA. Now back to the proposal, which is not about a > QUIC CLA. > > > > Where the draft goes wrong, I think, is in asserting that substituting > QUIC for TCP would make the BP stack unnecessary. > > > I for one tried hard to not say BP is unnecessary. I’m more saying that > there is an alternative proposal that may also work. It will be up to the > space organizations to decide which one (or both) they want to use. QUIC vs > TCP is not the full story. It is all the pieces together that make an > alternative to a BP infrastructure. > > > I think that's incorrect: > > - Supporting multiple concurrent flows over a single connection would > indeed achieve the same sort of continuous transmission that we already get > with LTP, a major plus. > > > We can do pros and cons of LTP vs QUIC. However, it should be noted that > there is an important difference between the two: > - QUIC is end to end, provides reliable transport over non reliable links, > TLS security end to end (setup in a single RTT), … so whatever the number > and the characteristics of the links in the network from one endpoint to > the other, it maintains its properties. > - LTP on the other end is on a per link basis. Therefore, to get its > benefits, one has to make sure that all links are using LTP. Applications > won’t be able to know that, they just have to believe it is the case. (For > those reading and not familiar, LTP is RFC5326 (Experimental status from > the dtnrg time; I know that a new version is being worked on in CCSDS). > > > > - > - Also, configuring QUIC for zero-RT would eliminate round trips in > re-establishing a previously established connection, another big plus. But > every connection with a new peer, > > > Given that a typical peer in space costs around $100M, that event won’t > happen often. But even if it happens « often », it is a one RTT to setup. > > Let’s say a ground software station wants to establish a connection to a > not yet known device (I have a hard time thinking that it would be the case > typically…) which is on Mars, then it would take a 40 minutes max (1RTT) to > establish the secured connection. Time it takes is not because of IP or > QUIC, but just the light time. Given that typically, these devices last for > quite some time, sometimes years, the actual « cost » of a single RTT to > establish the connection is marginal. Moreover, if you know (which is > pretty much the case!) in advance that you would be « talking » to this > device, one can establish the connection between the two peers before the > spacecraft leaves Earth, therefore it would be already « connected » > together when resuming communications later in space. > > > > - or with a peer whose location in the topology has changed, would > still require a handshake. > > > Only if there is a change in IP address or port. It remains to be seen how > such things (change of IP address/port) will happen « often » in space. But > even, It is a single RTT to confirm securely the two peers. Avoid DOS or > man in the middle or else attacks. Very secured. Tested on a wild > environment called the Internet… ;-) > > > > - LTP, on the other hand, can always begin transmission to a brand-new > or relocated node immediately upon the start of a communication > opportunity, as the parameters of that communication are always > pre-established when the LTP engine is notified of the change. > > > Per link basis. QUIC won’t need to care about link status changes, as it > is end to end. The link state changes are handled by lower levels (aka TVR). > > > > - > - QUIC, like TCP, thinks that flow control is implemented upon > reception of transmission authorizations. Christian Huitema proposed > asynchronous transmission of anticipatory "flow control credits" as a way > to make this work in space, and sure, you could modify the QUIC protocol in > this way. Just using rate control informed by contact plans - as LTP does > - is simpler. > - QUIC apparently thinks that measuring the link data rate and > sticking to that rate controls congestion. It does not. DTN congestion > control is a matter of limiting storage occupancy, not of matching the > transmission rate to the acknowledgment rate. > - Christian Huitema's experiment showed that QUIC can indeed convey > data reliably over 20-minute one-way light times, once you revise the code > and lengthen the timer intervals. But that is by far the simplest part of > reliable transmission over interplanetary links: accommodating continuous > changes in connectivity, link character, data rates, network topology, > forwarding rules, and required quality of service was not considered in any > way. > > > I let that cited person to respond to these. > > > > Obviously all of this stuff is software, and you can always modify > software to do anything you want. It is certainly possible to spend some > time and money modifying all of the many widely exercised IP protocols > > > Again, that I think is a false statement. Not that much of changes. The > draft talks about some « major » IP protocols in used today (probably for > the Internet, covering 99% of the traffic), but also says that some > investigation might be needed for other protocols. > > > in such a way that you reinvent what is already in the BP stack > > > I would claim the reverse. I found over years that the BP framework was > reinventing a lot of stuff that was already well defined in Internet > protocols. I’ll take one example. I would have preferred not to compare, > but I think we need to. (IP) Network management has gone through roughly > two iterations (I’m oversimplifying here) of protocol frameworks: SNMP+MIB > and then NETCONF-RESTCONF+YANG. There is quite a wealth of implementations, > data models, etc… for almost every kind of device. One can look at the yang > data model github repo. NETCONF is defined to be used over TCP or SSH: that > won’t work as is in deep space. NETCONF over QUIC is specified in a draft. > But RESTCONF is over HTTP. So right off, you can use everything defined > (including the YANG models being discussed in TVR at this time) in this > realm without changes (make sure you configure in the implementation the > timer for expiration to be longer than typical). On the other hand, I found > DTNMA (https://datatracker.ietf.org/doc/draft-ietf-dtn-dtnma/) to be very > complex, to read, to implement, and kind of reinventing the wheel. It may > have its own use, but again, if NETCONF-RESTCONF+YANG works, why redo? I’m > sure Ed will chime in on this. ;-) > > Another example. We tried some time ago to develop a native application > over BP: there was a project interested in looking at using BP. From the > application perspective, it just pass blobs of data to the BP node with the > destination endpoint id (i.e. « address »). There is no notion or > abstraction of a connection (on purpose). We end up doing a lot of > connection identification, state, payload ids and managing reordering, etc… > in the application layer. It is difficult to do that right and reliably in > an application. And then if you add the need for security, one has to rely > on BP security to be implemented from end to end and made it « known » to > the application: I don’t know of any BP implementation that enables this, > but I guess it could be done. While QUIC does all this, including security, > for you, free, in the single connection, with all the certificate/keys > framework we are using today. > > > – eliminating all connections and all client/server interactions – > > > Actually, I would, on the contrary, not eliminate any connection or > client/server interaction. I would keep them, but make sure they are > tolerant to delay and disruption. Some of that « dirty work » is done at > the transport and IP layer, so it is mostly invisible to the application > protocols and applications (with some care about timers as discussed > above), which is a big big plus. > > > and call it IP, and maybe that is what the industry will decide it prefers. > > What's unfortunate about such an initiative is that it would sap time and > resources from development and deployment of a protocol stack that we > already know will work at Mars without significant modification, since it > was shown to work at interplanetary distances (on the order of 1 light > minute, with link outages resulting in round-trip times on the order of > days), in space, 15 years ago. > > > I can’t respond to this except that I’m sorry to bring this now. It is > also the fact that things/protocols have evolved in parallel and got, IMHO, > an overall better solution. But I understand that I need to work hard to > convince you. > > > > As best I can tell, the only advantage of the proposed initiative is that > the IP stack's "implementations have been exercised on real traffic orders > of magnitude more than what has been achieved with Bundle Protocol > stacks." This is undeniable, but of course the same could have been said > about SNA or DECnet in the days before IP became widely supported. > > > I hope that argument (being exercised widely) to be taken the right way. I > think you are right that this should not be the only or primary reason for > choosing this new proposal. However, it secures a lot people using a > technology, when software has been exercised so much: way less chance to > have memory issues, crashes, … For a difficult environment such as space, > it is IMHO a very big plus. > > > > More to the point, we are not here talking about deploying that widely > exercised stack in space. We are talking about deploying an IP stack that > is operationally very different from what we use on Earth and which has not > yet been specified in detail, much less implemented, much less > demonstrated, much less exercised on even a tiny fraction of the traffic > conveyed between Earth and the International Space Station over the last > seven years of continuous science instrument support. > > > IP has been used in space. Just an example: it has been presented at a > recent IETF, by Cisco and Lockheed Martin (see: > https://www.youtube.com/watch?v=V8Xdr0DvGKE). Webex Earth to Orion > spacecraft. Don’t know if they were using QUIC, but WebRTC so > SIP-RTP-UDP-HTTPwebsockets. Some careful considerations, especially the use > of the right codec. But this is real-time two-way communications. Not sure > we want to do this as is in « far » deep space (aka Mars). > > > I am doubtful. > > > Understood. Hope that I, not by myself, but hopefully with the help of > others, will be able to convince you at some point. > > Regards, Marc. > > PS. Don’t want to overpromise, but we are working on a testbed to show the > whole stack with simulation of the various conditions as near to real > situations as possible. Will report results when done. > > > > Scott > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn > > > -- > Deepspace mailing list > Deepspace@ietf.org > https://www.ietf.org/mailman/listinfo/deepspace > > _______________________________________________ > dtn mailing list > dtn@ietf.org > https://www.ietf.org/mailman/listinfo/dtn >
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- [Deepspace] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks Marc Blanchet
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks Marc Blanchet
- Re: [Deepspace] [dtn] technical remarks Dean Bogdanovic
- Re: [Deepspace] [dtn] technical remarks Jorge Amodio
- Re: [Deepspace] [dtn] technical remarks Dean Bogdanovic
- Re: [Deepspace] [dtn] technical remarks Jorge Amodio
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks Marc Blanchet
- Re: [Deepspace] [dtn] technical remarks Marc Blanchet
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks Dean Bogdanovic
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks Dean Bogdanovic
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks Scott Johnson
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks Wesley Eddy
- Re: [Deepspace] [dtn] technical remarks Dean Bogdanovic
- Re: [Deepspace] [dtn] technical remarks Jorge Amodio
- Re: [Deepspace] [dtn] technical remarks Tony Li
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks Dean Bogdanovic
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks Tony Li
- Re: [Deepspace] [dtn] technical remarks Jeremy Harris
- Re: [Deepspace] [dtn] technical remarks Marc Blanchet
- Re: [Deepspace] [dtn] technical remarks Marc Blanchet
- Re: [Deepspace] [dtn] technical remarks Marc Blanchet
- [Deepspace] late binding (was RE: [dtn] technical… sburleig.sb
- Re: [Deepspace] late binding (was RE: [dtn] techn… Tony Li
- Re: [Deepspace] late binding (was RE: [dtn] techn… sburleig.sb
- Re: [Deepspace] [dtn] technical remarks Christian Huitema
- Re: [Deepspace] late binding (was RE: [dtn] techn… Tony Li
- Re: [Deepspace] late binding (was RE: [dtn] techn… sburleig.sb
- Re: [Deepspace] late binding (was RE: [dtn] techn… Tony Li
- Re: [Deepspace] late binding (was RE: [dtn] techn… sburleig.sb
- Re: [Deepspace] late binding (was RE: [dtn] techn… Marshall Eubanks
- Re: [Deepspace] late binding (was RE: [dtn] techn… Tony Li
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] late binding (was RE: techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- [Deepspace] end-to-end (was RE: [dtn] technical r… sburleig.sb
- Re: [Deepspace] [dtn] late binding (was RE: techn… Dean Bogdanovic
- Re: [Deepspace] [dtn] technical remarks Dean Bogdanovic
- Re: [Deepspace] [dtn] late binding (was RE: techn… Lloyd W
- Re: [Deepspace] [dtn] late binding (was RE: techn… Stephen Farrell
- Re: [Deepspace] late binding (was RE: [dtn] techn… Abdussalam Baryun
- Re: [Deepspace] late binding (was RE: [dtn] techn… Abdussalam Baryun
- Re: [Deepspace] late binding (was RE: [dtn] techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… sburleig.sb
- Re: [Deepspace] late binding (was RE: [dtn] techn… Abdussalam Baryun
- Re: [Deepspace] [dtn] late binding (was RE: techn… Marshall Eubanks
- Re: [Deepspace] [dtn] late binding (was RE: techn… Lloyd W
- Re: [Deepspace] [dtn] late binding (was RE: techn… Lloyd W
- Re: [Deepspace] late binding (was RE: [dtn] techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- Re: [Deepspace] [dtn] late binding (was RE: techn… Olivier De jonckere
- Re: [Deepspace] [dtn] late binding (was RE: techn… sburleig.sb
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] technical remarks Marc Blanchet
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- Re: [Deepspace] late binding (was RE: [dtn] techn… Lloyd W
- Re: [Deepspace] [dtn] late binding (was RE: techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… Olivier De jonckere
- Re: [Deepspace] [dtn] late binding (was RE: techn… scott
- Re: [Deepspace] late binding (was RE: [dtn] techn… sburleig.sb
- Re: [Deepspace] [dtn] late binding (was RE: techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… Marc Blanchet
- [Deepspace] time to live (was RE: [dtn] technical… sburleig.sb
- Re: [Deepspace] late binding (was RE: [dtn] techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… Scott Johnson
- Re: [Deepspace] [dtn] late binding (was RE: techn… sburleig.sb
- Re: [Deepspace] [dtn] late binding (was RE: techn… scott
- Re: [Deepspace] [dtn] late binding (was RE: techn… Dean Bogdanovic
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- Re: [Deepspace] [dtn] late binding (was RE: techn… Dean Bogdanovic
- Re: [Deepspace] [dtn] late binding (was RE: techn… Marshall Eubanks
- Re: [Deepspace] [dtn] late binding (was RE: techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- Re: [Deepspace] [dtn] late binding (was RE: techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… sburleig.sb
- Re: [Deepspace] [dtn] late binding (was RE: techn… Lloyd W
- Re: [Deepspace] [dtn] late binding (was RE: techn… sburleig.sb
- Re: [Deepspace] [dtn] late binding (was RE: techn… Alexandre Petrescu
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- Re: [Deepspace] end-to-end (was RE: [dtn] technic… Christian Huitema
- Re: [Deepspace] [dtn] late binding (was RE: techn… Marshall Eubanks
- Re: [Deepspace] [dtn] late binding (was RE: techn… Marc Blanchet
- Re: [Deepspace] [dtn] technical remarks Christian Huitema
- Re: [Deepspace] [dtn] late binding (was RE: techn… Dean Bogdanovic
- Re: [Deepspace] [dtn] late binding (was RE: techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- Re: [Deepspace] [dtn] technical remarks Marc Blanchet
- Re: [Deepspace] [dtn] technical remarks Stephen Farrell
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- Re: [Deepspace] [dtn] technical remarks Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… Marshall Eubanks
- Re: [Deepspace] [dtn] late binding (was RE: techn… Alexandre Petrescu
- Re: [Deepspace] late binding (was RE: [dtn] techn… Marc Blanchet
- Re: [Deepspace] [dtn] late binding (was RE: techn… Tomaso.deCola
- Re: [Deepspace] [dtn] late binding (was RE: techn… Marc Blanchet
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- Re: [Deepspace] [dtn] late binding (was RE: techn… Scott Johnson
- Re: [Deepspace] [dtn] late binding (was RE: techn… sburleig.sb
- Re: [Deepspace] [dtn] late binding (was RE: techn… Alexandre Petrescu
- Re: [Deepspace] late binding (was RE: [dtn] techn… sburleig.sb
- Re: [Deepspace] [dtn] late binding (was RE: techn… scott
- Re: [Deepspace] [dtn] late binding (was RE: techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… Alexandre Petrescu
- Re: [Deepspace] [dtn] late binding (was RE: techn… Alexandre Petrescu
- Re: [Deepspace] [dtn] late binding (was RE: techn… Alexandre Petrescu
- Re: [Deepspace] [dtn] late binding (was RE: techn… Marc Blanchet
- Re: [Deepspace] [dtn] technical remarks sburleig.sb
- Re: [Deepspace] [dtn] late binding (was RE: techn… Alexandre Petrescu
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- Re: [Deepspace] late binding (was RE: [dtn] techn… sburleig.sb
- Re: [Deepspace] [dtn] late binding (was RE: techn… Jorge Amodio
- Re: [Deepspace] [dtn] technical remarks Jeremy Harris
- Re: [Deepspace] [dtn] late binding (was RE: techn… Alexandre Petrescu
- Re: [Deepspace] [dtn] late binding (was RE: techn… RJA
- Re: [Deepspace] [dtn] late binding (was RE: techn… Alexandre Petrescu
- Re: [Deepspace] [dtn] late binding (was RE: techn… Marc Blanchet
- Re: [Deepspace] [dtn] late binding (was RE: techn… Marc Blanchet
- Re: [Deepspace] [dtn] late binding (was RE: techn… Tony Li
- Re: [Deepspace] [dtn] late binding (was RE: techn… Stephen Farrell
- Re: [Deepspace] late binding (was RE: [dtn] techn… Marc Blanchet
- Re: [Deepspace] [dtn] Flow control (was: technica… Christian Huitema
- [Deepspace] CCSDS preliminary packet and IPv6 (wa… Alexandre Petrescu
- Re: [Deepspace] [dtn] late binding (was RE: techn… RJA
- Re: [Deepspace] [dtn] late binding (was RE: techn… scott
- Re: [Deepspace] [dtn] late binding (was RE: techn… Stephen Farrell
- Re: [Deepspace] [dtn] late binding (was RE: techn… Marc Blanchet