From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5D1B13B2A4 for ; Sun, 12 Dec 2021 15:47:18 -0500 (EST) Received: by mail-wm1-x32d.google.com with SMTP id r9-20020a7bc089000000b00332f4abf43fso9985825wmh.0 for ; Sun, 12 Dec 2021 12:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CMuQwMTOIRxF/ebZ4obvdBtR7lhu1YW4CEATiX7dCAY=; b=JTLchVmHpB2kLF5oEcu1LjG/117EgiXEAYHEIQ5NR0ZvqZXblCsMcVRciEZqr076fI 7vrt1obD1ZLaO4MibxxjN9n+X1yqTzMt9ECzD06hSUikZsL0+ppAslRbr3TOkZUNevf9 45fgsImhl5TC475qlN3whMvEAwQmKB+fDgna2+30SfUrVttkX+g/bdO6V+9KM3yXWX3s g2QhftZA1nSk22g4zDTKiSlKyiLF1yHtsjwuz7f0pLYQjiyctTJi8LWZ77sShr7z5qmF CL3+DTRgjSnX6j0a0cr4M4e/DFbjKvVqhYmSt43lYrFV5enihb0mIhp+2BKuSr3Jv6hP QkYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CMuQwMTOIRxF/ebZ4obvdBtR7lhu1YW4CEATiX7dCAY=; b=6W8YlSQDYx/dD8lDfaIEIzLRgW9/553WPUlgjosBZAqNsEznPOjVM88JHhAvENVo5j TkIxQiU6A++yykVZBEMNnC0bbpHpNlJaoKcrr/7V2gGkYV3YD6mjA2djvr4r16C3T7B+ f2q0FUhAgbhjcxYPttZ6kU/7WNYICSOtu3AQ8wfqHaYqD/CY/ivzvHQ58OE61RH1HwDd 57zurjoL7BsaZUUZGUkIE3+Uk8CGYOFCODOwCDPTtuOCTdHlF88yXAjudGtP1D2l5pab v11hfto+OuNWeNVWXlanKn1y5xgeeJQuTrHGmMG000jZRoskqWs1A4KU31/nppQRGPzP HITA== X-Gm-Message-State: AOAM533Z7aN73D2mTmlFKFnwdcAcsAftJEo8qLZClDeThuXFjnz5ALN2 XOvl7L7AAbK9C9cCoBv7dW7FunJqQQrC6M7vVmRQuW9GYh8= X-Google-Smtp-Source: ABdhPJyWrF31eXfgefJdXujRRrCO8z05DsmdScADKKzfMS7b3FPYWJyByp2tk12fuHYjyw2yBcpUsOWNEaLhRehB8XM= X-Received: by 2002:a05:600c:4e02:: with SMTP id b2mr32857291wmq.105.1639342037060; Sun, 12 Dec 2021 12:47:17 -0800 (PST) MIME-Version: 1.0 References: <1639341564.906916211@apps.rackspace.com> In-Reply-To: <1639341564.906916211@apps.rackspace.com> From: Vint Cerf Date: Sun, 12 Dec 2021 15:47:05 -0500 Message-ID: To: "David P. Reed" Cc: starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000c92a2805d2f90fbb" Subject: Re: [Starlink] some details on the DTN, bundle protocol, and a capacity question X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2021 20:47:18 -0000 --000000000000c92a2805d2f90fbb Content-Type: text/plain; charset="UTF-8" I am a fan of Fountain codes - however, it only works if you have all the data you are going to send in hand before encoding. David, if there is a way to do this with data that is being generated on the fly with sensors, that would be of interest. Of course, one can "chunk" the data, fountain-code it, and reconstruct "chunks" on receipt. v On Sun, Dec 12, 2021 at 3:39 PM David P. Reed wrote: > It's worth noting that the patents on Bill Luby's digital fountain codes, > etc. have pretty much inhibited one of the best solutions for DTN out > there. There's one exception - RFC 6330, which has a very, very specific > use of the RaptorQ code specified in it. Qualcomm apparently negotiated a > license for that very specific use in that specific protocol, as long as it > is never used in "wide area wireless" (see the details of the narrow > license here) networking. https://datatracker.ietf.org/ipr/2554/ > > > > Rateless erasure codes of ANY kind appear to be covered by the claims in > the early Digital Fountain patents. > > > > Now why are rateless erasure codes important for DTN? Well, essentially > such codes have a *unique* property that is pretty surprising: > > > > The coded form of any N-bit message (composed of segments that can be > lost, e.g. checksummed frames that are deemed lost/erased if the checksum > fails), is an infinite sequence of non-identical segments. If a receiver > receives a subset of distinct segments, totalling N or more bits, the > entire N-bit message can be reconstructed. > > > > That's what makes the code "rateless" - it works for ANY error rate, and > is optimal for that error rate. > > > > To solve the DTN problem, you simply send each message as a sequence of > coded segments. No windowing is required, no retransmission of packets that > are lost on one hop is required. Eventually, the message gets delivered, > and it will take no more time than the error rate on the path requires. > > > > That's remarkable. > > > > There are of course some issues to resolve - when should a message source > assume that its message has been reliably and completely received by the > intended destination? > > This is the "end-to-end" problem. If there is a reverse channel, once a > message has been received, the receiver should, at least each time it > receives a segment of some already completed message, send a single ACK for > that message. > > > > Now this is great for talking to a spacecraft that has a very low speed > and noisy reverse channel. > > > > Any number of messages can be concurrently sent from any number of sources > (the requirement is that each message has a global unique ID). > > > > Fair sharing of a multiplexed deep-space network's resources among many > concurrent messages is a bit more tricky. That's where "early ACks" might > be used in an advanced erasure code (one I doubt has been patented fully, > at least I've never seen that). > > ----------------------------------- > > Now, my personal view about *patents* on communications protocols is very > severe: since interoperability is the *essence* of communications > protocols, the idea of patents is antithetical to the utiliity of > protocols. Just as mathematical algorithms should not be patentable subject > matter, neither should communications protocols (which are just algorithms > on a different abstract machine). > > > > Unfortunately, Luby, et al. have threatened litigation over and over, > stymieing attempts to get usage of their remarkable invention, outside a > few monopolistic or oligopolistic licensees. > > > > It looks like, even though the original patents are due to expire soon, > lots of effort is being made to insure that all possible derivable > techniques are being patented to extend this monopoly. > > > > Consequently, I'd suggest that someone might find a way to "buy out" the > inventors of these patents and their assignees. It's a cancerous growth. > > > > Imagine if we who built the Internet Protocols had filed patents on all > the techniques used in the Internet? Would Vint be sitting there counting > his royalties, and with a team of lawyers negotiating license agreements? > (I have an oar in this - I'd be there with Vint in the countinghouse, > probably, as a coinventor). > > > > Bill Luby, his advisors, etc. did a remarkable thing here. And like other > inventors, he ought to be rewarded for his invention. I have no problem > with that. What I have a problem with is the structure of patent law as it > exists today. It is socially counterproductive, and economically > counterproductive, when used in the way it is being used here. > > > > But that's just my opinion. > > > > PS: I am co-inventor of a fair number of patented inventions. I live in > this broken system. But, in the case of communications protocols > specifically, I think this stuff shouldn't be protected by patent rights. > > > > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > -- Please send any postal/overnight deliveries to: Vint Cerf 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice --000000000000c92a2805d2f90fbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am a fan of Fountain codes - however, it only works if y= ou have all the data you are going to send in hand before encoding.=C2=A0David, if there is a way to do this with data that is being generated on= the fly with sensors, that would be of interest.

= Of course, one can "chunk" the data, fountain-code it, and recons= truct "chunks" on receipt.=C2=A0

v
=


On Sun, Dec 12, 2021 at 3:39 PM David P. Reed <dpreed@deepplum.com> wrote:

It's worth noting that the patents on Bill Luby's digital fountai= n codes, etc. have pretty much inhibited one of the best solutions for DTN = out there. There's one exception - RFC 6330, which has a very, very spe= cific use of the RaptorQ code specified in it. Qualcomm apparently negotiat= ed a license for that very specific use in that specific protocol, as long = as it is never used in "wide area wireless" (see the details of t= he narrow license here) networking.=C2=A0https://datatracker.ietf.org/ipr/2554/

=C2=A0=

Ratele= ss erasure codes of ANY kind appear to be covered by the claims in the earl= y Digital Fountain patents.

=C2=A0=

Now wh= y are rateless erasure codes important for DTN? Well, essentially such code= s have a *unique* property that is pretty surprising:

=C2=A0=

The co= ded form of any N-bit message (composed of segments that can be lost, e.g. = checksummed frames that are deemed lost/erased if the checksum fails), is a= n infinite sequence of non-identical segments. If a receiver receives a sub= set of distinct segments, totalling N or more bits, the entire N-bit messag= e can be reconstructed.

=C2=A0=

That&#= 39;s what makes the code "rateless" - it works for ANY error rate= , and is optimal for that error rate.

=C2=A0=

To sol= ve the DTN problem, you simply send each message as a sequence of coded seg= ments. No windowing is required, no retransmission of packets that are lost= on one hop is required. Eventually, the message gets delivered, and it wil= l take no more time than the error rate on the path requires.

=C2=A0=

That&#= 39;s remarkable.=C2=A0

=C2=A0=

There = are of course some issues to resolve - when should a message source assume = that its message has been reliably and completely received by the intended = destination?

This i= s the "end-to-end" problem. If there is a reverse channel, once a= message has been received, the receiver should, at least each time it rece= ives a segment of some already completed message, send a single ACK for tha= t message.=C2=A0

=C2=A0=

Now th= is is great for talking to a spacecraft that has a very low speed and noisy= reverse channel.

=C2=A0=

Any nu= mber of messages can be concurrently sent from any number of sources (the r= equirement is that each message has a global unique ID).

=C2=A0=

Fair s= haring of a multiplexed deep-space network's resources among many concu= rrent messages is a bit more tricky. That's where "early ACks"= ; might be used in an advanced erasure code (one I doubt has been patented = fully, at least I've never seen that).

------= -----------------------------

Now, m= y personal view about *patents* on communications protocols is very severe:= since interoperability is the *essence* of communications protocols, the i= dea of patents is antithetical to the utiliity of protocols. Just as mathem= atical algorithms should not be patentable subject matter, neither should c= ommunications protocols (which are just algorithms on a different abstract = machine).

=C2=A0=

Unfort= unately, Luby, et al. have threatened litigation over and over, stymieing a= ttempts to get usage of their remarkable invention, outside a few monopolis= tic or oligopolistic licensees.

=C2=A0=

It loo= ks like, even though the original patents are due to expire soon, lots of e= ffort is being made to insure that all possible derivable techniques are be= ing patented to extend this monopoly.

=C2=A0=

Conseq= uently, I'd suggest that someone might find a way to "buy out"= ; the inventors of these patents and their assignees. It's a cancerous = growth.

=C2=A0=

Imagin= e if we who built the Internet Protocols had filed patents on all the techn= iques used in the Internet? Would Vint be sitting there counting his royalt= ies, and with a team of lawyers negotiating license agreements? (I have an = oar in this - I'd be there with Vint in the countinghouse, probably, as= a coinventor).

=C2=A0=

Bill L= uby, his advisors, etc. did a remarkable thing here. And like other invento= rs, he ought to be rewarded for his invention. I have no problem with that.= What I have a problem with is the structure of patent law as it exists tod= ay. It is socially counterproductive, and economically counterproductive, w= hen used in the way it is being used here.

=C2=A0=

But th= at's just my opinion.

=C2=A0=

PS: I = am co-inventor of a fair number of patented inventions. I live in this brok= en system. But, in the case of communications protocols specifically, I thi= nk this stuff shouldn't be protected by patent rights.

=C2=A0=

=C2=A0=

_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


--
Please send any postal/ove= rnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd=C2= =A0
McLean, VA 22102
703-448-0965

<= div>until further notice



=
--000000000000c92a2805d2f90fbb--