From geoff at iconia.com Wed Nov 25 11:59:20 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Wed, 25 Nov 2020 09:59:20 -1000 Subject: [ih] A Fair Code for an Open Internet (Vint Cerf) In-Reply-To: References: Message-ID: Australia is planning to introduce a new law that could undercut the principle of a free and open web. Here's my opinion: https://blog.google/around-the-globe/google-asia/australia/fair-code-open-internet/ via https://twitter.com/vgcerf/status/1331595075911102464 -- Geoff.Goodfellow at iconia.com living as The Truth is True From geoff at iconia.com Wed Nov 25 12:26:50 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Wed, 25 Nov 2020 10:26:50 -1000 Subject: [ih] =?utf-8?q?SpaceX_may_spend_billions_to_outsource_Starlink_s?= =?utf-8?q?atellite-dish_production=2C_an_industry_insider_says_?= =?utf-8?q?=E2=80=94_and_could_lose_=242=2C000_on_each_one_it_sells?= In-Reply-To: References: Message-ID: - *SpaceX recently launched a public beta test for Starlink, its growing network of internet-beaming satellites .* - *Test subscribers pay $100 per month for broadbandlike service , plus a $500 fee for a starter kit that includes a "UFO on a stick" user terminal, or satellite dish.* - *But each user terminal contains a phased-array antenna, which industry experts say can't be made for less than $1,000.* - *SpaceX hired STMicroelectronics to manufacture Starlink user terminals, a person with knowledge of the agreement told Business Insider.* - *The contract with the Swiss-headquartered manufacturing giant calls for the production of 1 million terminals and may be worth billions of dollars, the person said.* EXCERPT: SpaceX is outsourcing a key element of its Starlink satellite-internet network with a manufacturing deal worth billions of dollars, an industry insider told Business Insider. Job postings and statements by SpaceX officials ? including founder Elon Musk ? over the past two years indicate the company wants to make as many Starlink components as possible in-house at its facilities in Redmond, Washington. For example, SpaceX is building about six 550-pound satellites per day there, Jonathan Hofeller, the head of Starlink and commercial sales, said during an August conference. Company reps have revealed less about the production of its *consumer-facing Starlink user terminal* ? the satellite dish that allows customers to get service ? with questions around who's building them, where, and at what cost. In March, the Federal Communications Commission granted SpaceX's request to deploy 1 million of the units. In September, SpaceX told the agency that it was "on track to produce thousands of consumer user terminals per month" and "heading toward high-rate production." The trick to making that happen, information shared with Business Insider suggests, may be paying $2.4 billion to *STMicroelectronics* , a Swiss advanced-electronics manufacturing giant, to crank out 1 million Starlink user terminals. 'Our most difficult technical challenge'... [...] https://www.businessinsider.com/spacex-starlink-satellite-dish-user-terminal-cost-stmelectronics-outsource-manufacturer-2020-11 -- Geoff.Goodfellow at iconia.com living as The Truth is True From geoff at iconia.com Wed Nov 25 12:28:42 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Wed, 25 Nov 2020 10:28:42 -1000 Subject: [ih] =?utf-8?q?Starlink=27s_=22dishy=22_user_terminal_is_filled_?= =?utf-8?b?d2l0aCBSRiBtYWdpYyDinKjvv7zvv7zwn6eZ4oCN4pmC77iPIGFuZCBJ?= =?utf-8?q?_just_completed_the_first_full_teardown!_Check_it_out=3A?= =?utf-8?q?_=28Ken_Keiter=29?= In-Reply-To: References: Message-ID: https://www.youtube.com/watch?v=iOmdQnIlnRo via https://twitter.com/kenkeiter/status/1331584169563074560 -- Geoff.Goodfellow at iconia.com living as The Truth is True From steffen at sdaoden.eu Wed Nov 25 13:04:43 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 25 Nov 2020 22:04:43 +0100 Subject: [ih] =?utf-8?q?SpaceX_may_spend_billions_to_outsource_Starlink_s?= =?utf-8?q?atellite-dish_production=2C_an_industry_insider_says_=E2=80=94_?= =?utf-8?q?and_could_lose_=242=2C000_on_each_one_it_sells?= In-Reply-To: References: Message-ID: <20201125210443.slZTa%steffen@sdaoden.eu> the keyboard of geoff goodfellow wrote in : ... | - *SpaceX recently launched a public beta test for Starlink, its growing | network of internet-beaming satellites Sorry not to step in cheering this. I think now the time has come to raise massive taxes on these things which violate the heaven above. The sheer number of rocket resource needed to keep these lines closed is ridiculous. Is there any science going on on improving the situation regarding this? Space lift? And i am very, very thankful that at least the newer satellites of _that_ company seem to hide their solar panel reflections from the earth, it always have been moments of deeply felt hate seeing these (?) lines of satellites flying by (following each other within ~30 seconds), i personally would have shoot them. I know there are cultures on this world which feel the same. Thank you. (And i _love_ books, battered or not.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From geoff at iconia.com Wed Nov 25 15:07:09 2020 From: geoff at iconia.com (the keyboard of geoff goodfellow) Date: Wed, 25 Nov 2020 13:07:09 -1000 Subject: [ih] =?utf-8?q?SpaceX_may_spend_billions_to_outsource_Starlink_s?= =?utf-8?q?atellite-dish_production=2C_an_industry_insider_says_?= =?utf-8?q?=E2=80=94_and_could_lose_=242=2C000_on_each_one_it_sells?= In-Reply-To: <20201125210443.slZTa%steffen@sdaoden.eu> References: <20201125210443.slZTa%steffen@sdaoden.eu> Message-ID: in late May: --> SpaceX submitted an application to the FCC for its second generation system of 30,000 Non-Geostationary (NGSO) satellites https://fcc.report/IBFS/SAT-LOA-20200526-00055/2378669.pdf via https://www.satellitetoday.com/launch/2020/06/04/spacex-launches-60-more-starlink-satellites-2/ --> OneWeb has told the FCC that it wants to increase the number of satellites in its constellation to 48,000, viz.: https://www.satellitetoday.com/broadband/2020/05/27/oneweb-explains-fcc-application-for-48000-constellation-satellites/ and at the end of July: --> The FCC granted Amazon approval on Thursday to build out Project Kuiper, its planned constellation of 3,236 satellites in Low-Earth Orbit https://www.satellitetoday.com/broadband/2020/07/31/fcc-approves-amazons-kuiper-constellation/ On Wed, Nov 25, 2020 at 11:12 AM Steffen Nurpmeso wrote: > the keyboard of geoff goodfellow wrote in > : > ... > | - *SpaceX recently launched a public beta test for Starlink, its > growing > | network of internet-beaming satellites > > Sorry not to step in cheering this. > I think now the time has come to raise massive taxes on these > things which violate the heaven above. > The sheer number of rocket resource needed to keep these lines > closed is ridiculous. Is there any science going on on improving > the situation regarding this? Space lift? > And i am very, very thankful that at least the newer satellites of > _that_ company seem to hide their solar panel reflections from the > earth, it always have been moments of deeply felt hate seeing > these (?) lines of satellites flying by (following each other > within ~30 seconds), i personally would have shoot them. > I know there are cultures on this world which feel the same. > > Thank you. > (And i _love_ books, battered or not.) > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > > -- Geoff.Goodfellow at iconia.com living as The Truth is True From lpress at csudh.edu Wed Nov 25 22:12:58 2020 From: lpress at csudh.edu (Larry Press) Date: Thu, 26 Nov 2020 06:12:58 +0000 Subject: [ih] =?windows-1252?q?SpaceX_may_spend_billions_to_outsource_Sta?= =?windows-1252?q?rlink_satellite-dish_production=2C_an_industry_insider_s?= =?windows-1252?q?ays_=97_and_could_lose_=242=2C000_on_each_one_it_sells?= In-Reply-To: <20201125210443.slZTa%steffen@sdaoden.eu> References: , <20201125210443.slZTa%steffen@sdaoden.eu> Message-ID: > I think now the time has come to raise massive taxes on these things which violate the heaven above. Who would you have the tax paid to? The UN perhaps? From ocl at gih.com Thu Nov 26 01:23:58 2020 From: ocl at gih.com (=?UTF-8?Q?Olivier_MJ_Cr=c3=a9pin-Leblond?=) Date: Thu, 26 Nov 2020 10:23:58 +0100 Subject: [ih] =?utf-8?q?SpaceX_may_spend_billions_to_outsource_Starlink_s?= =?utf-8?q?atellite-dish_production=2C_an_industry_insider_says_=E2=80=94_?= =?utf-8?q?and_could_lose_=242=2C000_on_each_one_it_sells?= In-Reply-To: References: <20201125210443.slZTa%steffen@sdaoden.eu> Message-ID: I presume that all of these satellites will be located above the United States, or does the FCC have jurisdiction over the whole world's airspace? The other question I have is what makes this offering different to past failed LEO offerings? We're told "this time it will be different" yet the world's moving towards a better and more efficient use of resources (it needs to) and there's nothing green about a LEO network. Remember that the earth's gravity has not changed in the past 20 years. Unless someone's worked on it, it remains at 9.80665 m/s^2. What goes up must come down. the lifetime of a LEO satellite is anything between 5 to 7 years. Kindest regards, Olivier On 26/11/2020 00:07, the keyboard of geoff goodfellow via Internet-history wrote: > in late May: > > --> SpaceX submitted an application to the FCC for its second generation > system of 30,000 Non-Geostationary (NGSO) satellites > https://fcc.report/IBFS/SAT-LOA-20200526-00055/2378669.pdf > via > https://www.satellitetoday.com/launch/2020/06/04/spacex-launches-60-more-starlink-satellites-2/ > > --> OneWeb has told the FCC that it wants to increase the number of > satellites in its constellation to 48,000, viz.: > https://www.satellitetoday.com/broadband/2020/05/27/oneweb-explains-fcc-application-for-48000-constellation-satellites/ > > and at the end of July: > > --> The FCC granted Amazon approval on Thursday to build out Project > Kuiper, its planned constellation of 3,236 satellites in Low-Earth Orbit > https://www.satellitetoday.com/broadband/2020/07/31/fcc-approves-amazons-kuiper-constellation/ > > > On Wed, Nov 25, 2020 at 11:12 AM Steffen Nurpmeso > wrote: > >> the keyboard of geoff goodfellow wrote in >> : >> ... >> | - *SpaceX recently launched a public beta test for Starlink, its >> growing >> | network of internet-beaming satellites >> >> Sorry not to step in cheering this. >> I think now the time has come to raise massive taxes on these >> things which violate the heaven above. >> The sheer number of rocket resource needed to keep these lines >> closed is ridiculous. Is there any science going on on improving >> the situation regarding this? Space lift? >> And i am very, very thankful that at least the newer satellites of >> _that_ company seem to hide their solar panel reflections from the >> earth, it always have been moments of deeply felt hate seeing >> these (?) lines of satellites flying by (following each other >> within ~30 seconds), i personally would have shoot them. >> I know there are cultures on this world which feel the same. >> >> Thank you. >> (And i _love_ books, battered or not.) >> >> --steffen >> | >> |Der Kragenbaer, The moon bear, >> |der holt sich munter he cheerfully and one by one >> |einen nach dem anderen runter wa.ks himself off >> |(By Robert Gernhardt) >> >> From joly at punkcast.com Thu Nov 26 03:16:17 2020 From: joly at punkcast.com (Joly MacFie) Date: Thu, 26 Nov 2020 06:16:17 -0500 Subject: [ih] =?utf-8?q?SpaceX_may_spend_billions_to_outsource_Starlink_s?= =?utf-8?q?atellite-dish_production=2C_an_industry_insider_says_?= =?utf-8?q?=E2=80=94_and_could_lose_=242=2C000_on_each_one_it_sells?= In-Reply-To: References: <20201125210443.slZTa%steffen@sdaoden.eu> Message-ID: One assumes that Musk has done the math. I read a while back that he expects Starlink to fund the entire Mars effort. joly On Thu, Nov 26, 2020 at 4:23 AM Olivier MJ Cr?pin-Leblond via Internet-history wrote: > I presume that all of these satellites will be located above the United > States, or does the FCC have jurisdiction over the whole world's airspace? > > The other question I have is what makes this offering different to past > failed LEO offerings? We're told "this time it will be different" yet > the world's moving towards a better and more efficient use of resources > (it needs to) and there's nothing green about a LEO network. Remember > that the earth's gravity has not changed in the past 20 years. Unless > someone's worked on it, it remains at 9.80665 m/s^2. What goes up must > come down. the lifetime of a LEO satellite is anything between 5 to 7 > years. > Kindest regards, > > Olivier > > On 26/11/2020 00:07, the keyboard of geoff goodfellow via > Internet-history wrote: > > in late May: > > > > --> SpaceX submitted an application to the FCC for its second generation > > system of 30,000 Non-Geostationary (NGSO) satellites > > https://fcc.report/IBFS/SAT-LOA-20200526-00055/2378669.pdf > > via > > > https://www.satellitetoday.com/launch/2020/06/04/spacex-launches-60-more-starlink-satellites-2/ > > > > --> OneWeb has told the FCC that it wants to increase the number of > > satellites in its constellation to 48,000, viz.: > > > https://www.satellitetoday.com/broadband/2020/05/27/oneweb-explains-fcc-application-for-48000-constellation-satellites/ > > > > and at the end of July: > > > > --> The FCC granted Amazon approval on Thursday to build out Project > > Kuiper, its planned constellation of 3,236 satellites in Low-Earth Orbit > > > https://www.satellitetoday.com/broadband/2020/07/31/fcc-approves-amazons-kuiper-constellation/ > > > > > > On Wed, Nov 25, 2020 at 11:12 AM Steffen Nurpmeso > > wrote: > > > >> the keyboard of geoff goodfellow wrote in > >> : > >> ... > >> | - *SpaceX recently launched a public beta test for Starlink, its > >> growing > >> | network of internet-beaming satellites > >> > >> Sorry not to step in cheering this. > >> I think now the time has come to raise massive taxes on these > >> things which violate the heaven above. > >> The sheer number of rocket resource needed to keep these lines > >> closed is ridiculous. Is there any science going on on improving > >> the situation regarding this? Space lift? > >> And i am very, very thankful that at least the newer satellites of > >> _that_ company seem to hide their solar panel reflections from the > >> earth, it always have been moments of deeply felt hate seeing > >> these (?) lines of satellites flying by (following each other > >> within ~30 seconds), i personally would have shoot them. > >> I know there are cultures on this world which feel the same. > >> > >> Thank you. > >> (And i _love_ books, battered or not.) > >> > >> --steffen > >> | > >> |Der Kragenbaer, The moon bear, > >> |der holt sich munter he cheerfully and one by one > >> |einen nach dem anderen runter wa.ks himself off > >> |(By Robert Gernhardt) > >> > >> > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > -- -------------------------------------- Joly MacFie +12185659365 -------------------------------------- - From jeanjour at comcast.net Thu Nov 26 06:17:40 2020 From: jeanjour at comcast.net (John Day) Date: Thu, 26 Nov 2020 09:17:40 -0500 Subject: [ih] =?utf-8?q?SpaceX_may_spend_billions_to_outsource_Starlink_s?= =?utf-8?q?atellite-dish_production=2C_an_industry_insider_says_=E2=80=94_?= =?utf-8?q?and_could_lose_=242=2C000_on_each_one_it_sells?= In-Reply-To: References: <20201125210443.slZTa%steffen@sdaoden.eu> Message-ID: <36F1CE76-BD46-4555-8649-43B1E781A89F@comcast.net> Time to re-read, Heinlein?s The Man Who Sold the Moon. ;-) > On Nov 26, 2020, at 04:23, Olivier MJ Cr?pin-Leblond via Internet-history wrote: > > I presume that all of these satellites will be located above the United States, or does the FCC have jurisdiction over the whole world's airspace? > > The other question I have is what makes this offering different to past failed LEO offerings? We're told "this time it will be different" yet the world's moving towards a better and more efficient use of resources (it needs to) and there's nothing green about a LEO network. Remember that the earth's gravity has not changed in the past 20 years. Unless someone's worked on it, it remains at 9.80665 m/s^2. What goes up must come down. the lifetime of a LEO satellite is anything between 5 to 7 years. > Kindest regards, > > Olivier > > On 26/11/2020 00:07, the keyboard of geoff goodfellow via Internet-history wrote: >> in late May: >> >> --> SpaceX submitted an application to the FCC for its second generation >> system of 30,000 Non-Geostationary (NGSO) satellites >> https://fcc.report/IBFS/SAT-LOA-20200526-00055/2378669.pdf >> via >> https://www.satellitetoday.com/launch/2020/06/04/spacex-launches-60-more-starlink-satellites-2/ >> >> --> OneWeb has told the FCC that it wants to increase the number of >> satellites in its constellation to 48,000, viz.: >> https://www.satellitetoday.com/broadband/2020/05/27/oneweb-explains-fcc-application-for-48000-constellation-satellites/ >> >> and at the end of July: >> >> --> The FCC granted Amazon approval on Thursday to build out Project >> Kuiper, its planned constellation of 3,236 satellites in Low-Earth Orbit >> https://www.satellitetoday.com/broadband/2020/07/31/fcc-approves-amazons-kuiper-constellation/ >> >> >> On Wed, Nov 25, 2020 at 11:12 AM Steffen Nurpmeso >> wrote: >> >>> the keyboard of geoff goodfellow wrote in >>> : >>> ... >>> | - *SpaceX recently launched a public beta test for Starlink, its >>> growing >>> | network of internet-beaming satellites >>> >>> Sorry not to step in cheering this. >>> I think now the time has come to raise massive taxes on these >>> things which violate the heaven above. >>> The sheer number of rocket resource needed to keep these lines >>> closed is ridiculous. Is there any science going on on improving >>> the situation regarding this? Space lift? >>> And i am very, very thankful that at least the newer satellites of >>> _that_ company seem to hide their solar panel reflections from the >>> earth, it always have been moments of deeply felt hate seeing >>> these (?) lines of satellites flying by (following each other >>> within ~30 seconds), i personally would have shoot them. >>> I know there are cultures on this world which feel the same. >>> >>> Thank you. >>> (And i _love_ books, battered or not.) >>> >>> --steffen >>> | >>> |Der Kragenbaer, The moon bear, >>> |der holt sich munter he cheerfully and one by one >>> |einen nach dem anderen runter wa.ks himself off >>> |(By Robert Gernhardt) >>> >>> > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history From steffen at sdaoden.eu Thu Nov 26 14:29:59 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 26 Nov 2020 23:29:59 +0100 Subject: [ih] =?utf-8?q?SpaceX_may_spend_billions_to_outsource_Starlink_s?= =?utf-8?q?atellite-dish_production=2C_an_industry_insider_says_=E2=80=94_?= =?utf-8?q?and_could_lose_=242=2C000_on_each_one_it_sells?= In-Reply-To: References: <20201125210443.slZTa%steffen@sdaoden.eu> Message-ID: <20201126222959.oKNlq%steffen@sdaoden.eu> Larry Press wrote in : |> I think now the time has come to raise massive taxes on these |things which violate the heaven above. | |Who would you have the tax paid to? The UN perhaps? I feel happy to response in a way that may appear offensive :-)) Of course the countries where the service is used. You know it may not matter anymore for America since the ship of proper infrastructure anywhere else but in bigger cities has sailed at least three decades ago, with many households living on debts already in the 70s, as far as i know, and of course with the middle class and normal workers being f....d up almost completely (says also The Boss, and Iggy, ++), and of course America itself (recalling that "how big you have to be not to become busted" from early 90s that was heard from there), and that was before they say No. 45 burnt 5 billion dollars in three years before 2020. But here we do have little businesses and a still _somewhat_ alive village and city infrastructure, with people living and living people, and if it would be me then Amazon and any such player with terrible working conditions would get imposed conditions to nowhere. And for a reason. And for a reason of responsibility, humanity, and social freedom. The same is true for network infrastructure too, we do not need Satellites for normal operation here (despite some regions actually would need it, i have heard even some very poor African countries have better mobile communications infrastructure than some regions of Germany), and we have lots of people working on that. Mind you, not far away is a "major" mast, and i have seen people from all over Germany, but also from Spain, Czechia and Poland working there! (The latter three i personally count as indications how much pressure there is in the market already, but would do i know.) Also large lent mobile cranes for bigger updates, also a business. So it seems to me here is smart takeover of a string of professions and rather average rather local people in favour of some high technology (or pseudo-high technology) ones somewhere at the other end of the world. No. I am totally with the President of France, Emmanuel Macron, and i loved him saying "let's face it, we only have one Planet" (that was in America and this is -> !), and he was the one who first imagined Blue Helmet actions (?) against Brazil or other (conscious) destroyers of irretrievable treasures. We all know most of that will be used for soj for the MEAT! the white man wants, especially you, America. Finally i personally am totally pissed by the misuse of all the U* organizations, as well as the Nobel Price, for political, and that almost a hundred percent means pro-nato, pro-america, shit reasons. Not that i am naive enough to hope that we, the western world, will stop the misuse and stop that countdown-for-war! pattern. But Imagine we would. To end this positively, never forgot the day he was shot in New York, fourty years ago. (Non-representative) Ciao from Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Thu Nov 26 14:43:00 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 26 Nov 2020 23:43:00 +0100 Subject: [ih] =?utf-8?q?SpaceX_may_spend_billions_to_outsource_Starlink_s?= =?utf-8?q?atellite-dish_production=2C_an_industry_insider_says_=E2=80=94_?= =?utf-8?q?and_could_lose_=242=2C000_on_each_one_it_sells?= In-Reply-To: <20201126222959.oKNlq%steffen@sdaoden.eu> References: <20201125210443.slZTa%steffen@sdaoden.eu> <20201126222959.oKNlq%steffen@sdaoden.eu> Message-ID: <20201126224300.rnloj%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20201126222959.oKNlq%steffen at sdaoden.eu>: |Larry Press wrote in | : ||> I think now the time has come to raise massive taxes on these ||things which violate the heaven above. || ||Who would you have the tax paid to? The UN perhaps? | |I feel happy to response in a way that may appear offensive :-)) |Of course the countries where the service is used. ... |But here we do have little businesses and a still _somewhat_ alive |village and city infrastructure, with people living and living Not to forget widely available truly clean un-fracked drinking water and minimally acceptable use of chemicals in agriculture. Of course we treat animal heart and souls that every halfways empathic individual has to cry, it is a shame. And that's all. Anyhow, all this imposes pressure on the world, and does so for a long time. (I do _by far_ __not__ exclude Germany from the latter sentence.) Good night. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From lpress at csudh.edu Thu Nov 26 15:58:56 2020 From: lpress at csudh.edu (Larry Press) Date: Thu, 26 Nov 2020 23:58:56 +0000 Subject: [ih] =?windows-1252?q?SpaceX_may_spend_billions_to_outsource_Sta?= =?windows-1252?q?rlink_satellite-dish_production=2C_an_industry_insider_s?= =?windows-1252?q?ays_=97_and_could_lose_=242=2C000_on_each_one_it_sells?= In-Reply-To: <20201126224300.rnloj%steffen@sdaoden.eu> References: <20201125210443.slZTa%steffen@sdaoden.eu> <20201126222959.oKNlq%steffen@sdaoden.eu>, <20201126224300.rnloj%steffen@sdaoden.eu> Message-ID: I suggested the UN because Starlink, et al utilize a global commons that must be maintained -- kept clear debris and regulated. Larry From steffen at sdaoden.eu Fri Nov 27 09:54:44 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 27 Nov 2020 18:54:44 +0100 Subject: [ih] =?utf-8?q?SpaceX_may_spend_billions_to_outsource_Starlink_s?= =?utf-8?q?atellite-dish_production=2C_an_industry_insider_says_=E2=80=94_?= =?utf-8?q?and_could_lose_=242=2C000_on_each_one_it_sells?= In-Reply-To: References: <20201125210443.slZTa%steffen@sdaoden.eu> <20201126222959.oKNlq%steffen@sdaoden.eu> <20201126224300.rnloj%steffen@sdaoden.eu> Message-ID: <20201127175444.sUVup%steffen@sdaoden.eu> Larry Press wrote in : |I suggested the UN because Starlink, et al utilize a global commons \ |that must be maintained -- kept clear debris and regulated. Hard to imagine someone cares about the "common" state of oceans, or anything else. And if, mostly a local temporary time passage that will pass sooner or later, as it always have been. Well i do not know. As far as i know most things are now scheduled to regulary burn in atmosphere, there have been political pressure storms once debris was actively produced (it has to fit, however). All very political. Surrounding the topic space debris many, many suggestions over the last decades could be read about in the media. But just as McDonalds (mostly, here) is not granted responsibility for all the thrown-away dishes etc. that their consumers do no longer care about, and which have to be removed at the cost of tax payers (if at all [possible], and that is how it is done here) ... Not to be misunderstood, i personally am all in favour of what the original U[NO++] idea, as i understand it, was all about. But that is just Monkey business, for most types of monkey, building alliances and "cells of power", and everyone who makes it to the top as part of such, earns a bit (more), here and there. You have to reflect and change yourself, and that would have to be reflected by politics, covered by powerful politics, all the time, in order to reach a truly civilized "higher" stage of being. I do not see this for major players. Sometimes not at all. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From salo at saloits.com Sat Nov 28 15:42:45 2020 From: salo at saloits.com (Timothy J. Salo) Date: Sat, 28 Nov 2020 17:42:45 -0600 Subject: [ih] UDP Length Field? Message-ID: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> Hi, Can anyone provide some [historical] insight into why the UDP header contains a length field? TCP manages to ascertain the length of data in a packet just fine without a length field, so why couldn't UDP? Several people have noted that the UDP length field is redundant, including for example, the current Internet Draft "Transport Options for UDP", . There are some other opinions, some of which sound to me like after-the-fact reasoning: - So that UDP can run over network protocols other than IP (although presumably TCP could do this just fine without a length field). But, the UDP spec says that an IP-like pseudo header needs to be created, in any case. - Layering and encapsulation reasons, (although, again, TCP seems like a counter example). - Word alignment, (there were 16-bits left over, so why not use it for the length?). Personally, this sounds the most likely to me. Thanks, -tjs From brian.e.carpenter at gmail.com Sat Nov 28 17:20:52 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sun, 29 Nov 2020 14:20:52 +1300 Subject: [ih] UDP Length Field? In-Reply-To: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> Message-ID: <96e68aae-1f98-b62a-626e-3100f55869cb@gmail.com> Reverse designing it (a bit like reverse engineering), it seems useful to be able to check that the intended payload length fits inside the actual packet length. If it doesn't, you are exposed to what you might call buffer underrun issues. Conversely, if you don't like covert channels, you might want to detect any spare bits after the payload. Regards Brian Carpenter On 29-Nov-20 12:42, Timothy J. Salo via Internet-history wrote: > Hi, > > Can anyone provide some [historical] insight into why the UDP header > contains a length field? TCP manages to ascertain the length of data in > a packet just fine without a length field, so why couldn't UDP? > > Several people have noted that the UDP length field is redundant, > including for example, the current Internet Draft "Transport Options for > UDP", > . > > There are some other opinions, some of which sound to me like > after-the-fact reasoning: > > - So that UDP can run over network protocols other than IP (although > presumably TCP could do this just fine without a length field). But, > the UDP spec says that an IP-like pseudo header needs to be created, > in any case. > > - Layering and encapsulation reasons, (although, again, TCP seems like > a counter example). > > - Word alignment, (there were 16-bits left over, so why not use it for > the length?). Personally, this sounds the most likely to me. > > Thanks, > > -tjs > From jack at 3kitty.org Sat Nov 28 18:16:57 2020 From: jack at 3kitty.org (Jack Haverty) Date: Sat, 28 Nov 2020 18:16:57 -0800 Subject: [ih] UDP Length Field? In-Reply-To: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> Message-ID: <59942af3-27d5-c690-eb71-b5a5c1110ed1@3kitty.org> It's been a long time (40 years), but I remember the meetings circa 1980 where we split the original TCP header into the separate TCP and IP headers.?? I can't recall most of the discussion, but I remember the motivation for defining UDP was driven by the desire to experiment with things like voice, using quick but unguaranteed delivery, as well as actions that could be carried out with a single command/response interaction.?? That also motivated inclusion of functionality such as TOS, so that different kinds of use of IP could get different types of service most suitable for reliable-stream versus voice. The definition of UDP was done in a few hours, and intended for experimental use.? On the ARPANET, there was a "datagram mode" which provided similar unsequenced, non-guaranteed service as did UDP.? But ARPANET management rarely permitted datagram mode to be used, fearing that it might bring down the network.? So a backlog of desired experimentation with datagrams had built up, and UDP was the vehicle for exploring such ideas in the Internet context. I don't recall exactly which experimental usage scenarios drove the specifics of UDP, in particular why there is a length field.?? That was very much a time of "rough consensus and running code", so as a header format appeared on the board at the front of the room, and there were no strong objections, it became UDP.?? We were expecting that it would change as experimental results made the needs more clear, and didn't really expect that the suite of protocols would set in concrete so quickly and last so long. I do recall that one plausible usage scenario was to send multiple UDP payloads within one IP datagram.?? The Length field made that possible.? I don't remember the exact details, but it may have been an early idea associated with doing multi-casting.?? Perhaps the MBONE used it -- I don't remember...? /Jack Haverty On 11/28/20 3:42 PM, Timothy J. Salo via Internet-history wrote: > Hi, > > Can anyone provide some [historical] insight into why the UDP header > contains a length field?? TCP manages to ascertain the length of data in > a packet just fine without a length field, so why couldn't UDP? > > Several people have noted that the UDP length field is redundant, > including for example, the current Internet Draft "Transport Options for > UDP", > . > > There are some other opinions, some of which sound to me like > after-the-fact reasoning: > > - So that UDP can run over network protocols other than IP (although > ? presumably TCP could do this just fine without a length field).? But, > ? the UDP spec says that an IP-like pseudo header needs to be created, > ? in any case. > > - Layering and encapsulation reasons, (although, again, TCP seems like > ? a counter example). > > - Word alignment, (there were 16-bits left over, so why not use it for > ? the length?).? Personally, this sounds the most likely to me. > > Thanks, > > -tjs From brian.e.carpenter at gmail.com Sat Nov 28 19:00:53 2020 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sun, 29 Nov 2020 16:00:53 +1300 Subject: [ih] UDP Length Field? In-Reply-To: <59942af3-27d5-c690-eb71-b5a5c1110ed1@3kitty.org> References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> <59942af3-27d5-c690-eb71-b5a5c1110ed1@3kitty.org> Message-ID: David Reed might be able to answer. https://www.deepplum.com/blog-dpr/?page_id=6 Regards Brian Carpenter On 29-Nov-20 15:16, Jack Haverty via Internet-history wrote: > It's been a long time (40 years), but I remember the meetings circa 1980 > where we split the original TCP header into the separate TCP and IP > headers.?? I can't recall most of the discussion, but I remember the > motivation for defining UDP was driven by the desire to experiment with > things like voice, using quick but unguaranteed delivery, as well as > actions that could be carried out with a single command/response > interaction.?? That also motivated inclusion of functionality such as > TOS, so that different kinds of use of IP could get different types of > service most suitable for reliable-stream versus voice. > > The definition of UDP was done in a few hours, and intended for > experimental use.? On the ARPANET, there was a "datagram mode" which > provided similar unsequenced, non-guaranteed service as did UDP.? But > ARPANET management rarely permitted datagram mode to be used, fearing > that it might bring down the network.? So a backlog of desired > experimentation with datagrams had built up, and UDP was the vehicle for > exploring such ideas in the Internet context. > > I don't recall exactly which experimental usage scenarios drove the > specifics of UDP, in particular why there is a length field.?? That was > very much a time of "rough consensus and running code", so as a header > format appeared on the board at the front of the room, and there were no > strong objections, it became UDP.?? We were expecting that it would > change as experimental results made the needs more clear, and didn't > really expect that the suite of protocols would set in concrete so > quickly and last so long. > > I do recall that one plausible usage scenario was to send multiple UDP > payloads within one IP datagram.?? The Length field made that possible.? > I don't remember the exact details, but it may have been an early idea > associated with doing multi-casting.?? Perhaps the MBONE used it -- I > don't remember...? > > /Jack Haverty > > > On 11/28/20 3:42 PM, Timothy J. Salo via Internet-history wrote: >> Hi, >> >> Can anyone provide some [historical] insight into why the UDP header >> contains a length field?? TCP manages to ascertain the length of data in >> a packet just fine without a length field, so why couldn't UDP? >> >> Several people have noted that the UDP length field is redundant, >> including for example, the current Internet Draft "Transport Options for >> UDP", >> . >> >> There are some other opinions, some of which sound to me like >> after-the-fact reasoning: >> >> - So that UDP can run over network protocols other than IP (although >> ? presumably TCP could do this just fine without a length field).? But, >> ? the UDP spec says that an IP-like pseudo header needs to be created, >> ? in any case. >> >> - Layering and encapsulation reasons, (although, again, TCP seems like >> ? a counter example). >> >> - Word alignment, (there were 16-bits left over, so why not use it for >> ? the length?).? Personally, this sounds the most likely to me. >> >> Thanks, >> >> -tjs > From touch at strayalpha.com Sat Nov 28 19:48:10 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 28 Nov 2020 19:48:10 -0800 Subject: [ih] UDP Length Field? In-Reply-To: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> Message-ID: <67FDFE47-E933-44BE-958C-EC7F3C1C2636@strayalpha.com> Hi, all, FYI - Vint Carf is on this list and I?ve already reached out off-list to Bob Kahn. I?ll also reach out to others that might know (notably Carl Sunshine). > On Nov 28, 2020, at 3:42 PM, Timothy J. Salo via Internet-history wrote: > > Hi, > > Can anyone provide some [historical] insight into why the UDP header > contains a length field? TCP manages to ascertain the length of data in > a packet just fine without a length field, so why couldn't UDP? It can; IP includes its own length field so it can travel over links that don?t necessarily include length delimiters. > Several people have noted that the UDP length field is redundant, > including for example, the current Internet Draft "Transport Options for > UDP", > . As author of that doc, I?d point out RFC 6081 as the other primary example, which came with a defensive patent. However, that document seems to try to use the UDP length to point longer than the IP length would indicate, rather than shorter (as currently proposed for UDP options). The idea of using the UDP length field for multiple UDP segments in the same IP packet makes the most sense to me, but isn?t mentioned in the two precursor versions (IEN 71, IEN 88). It?s also counter to IEN 72, in which Postel introduces a ?multiplexing protocol? that provides its own protocol/length header that can be repeated to allow for multiple UDP, TCP, or (presumably) other transport protocols to be included in a single IP datagram. The example in that document shows the UDP length field and it being redundant with the multiplexing protocol even at that time. Joe From wayne at playaholic.com Sat Nov 28 21:44:23 2020 From: wayne at playaholic.com (Wayne Hathaway) Date: Sun, 29 Nov 2020 00:44:23 -0500 Subject: [ih] UDP Length Field? In-Reply-To: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> Message-ID: <1606628663.gado418l8gsg80wg@hostingemail.digitalspace.net> I worked for a few years for Auspex Systems, which made network-attached storage systems using NFS, which uses UDP. I don't know the reasoning behind including a length field, but note that the NFS header within the UDP datagram is variable length.? I noticed that by using the UDP length field, I could do a significant optimization when reading incoming datagrams. For example, if the UDP length was 8284 bytes, it was a very good guess that the arriving packet had an NFS header of 92 bytes and a data field of 8192 bytes.? So I would arrange to read the packet into a location such that the assumed 8192-byte data field would be aligned on a page boundary, allowing me to use the paging hardware rather than physically copying the data.?? (The Auspex hardware allowed me to make such a decision as data was arriving.)? If the assumption was wrong then I would do copies to handle it, but the vast majority of the time the assumption was correct, providing a significant performance boost.? In fact, because of optimizations like this, my first release of the paging-swapping network code slightly more than doubled Auspex's already-impressive NFS performance. So for whatever reason UDP included a length field, thank you!? :-) From touch at strayalpha.com Sat Nov 28 22:14:46 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sat, 28 Nov 2020 22:14:46 -0800 Subject: [ih] UDP Length Field? In-Reply-To: <1606628663.gado418l8gsg80wg@hostingemail.digitalspace.net> References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> <1606628663.gado418l8gsg80wg@hostingemail.digitalspace.net> Message-ID: > On Nov 28, 2020, at 9:44 PM, Wayne Hathaway via Internet-history wrote: > > I worked for a few years for Auspex Systems, which made network-attached storage systems using NFS, which uses UDP. I don't know the reasoning behind including a length field, but note that the NFS header within the UDP datagram is variable length. I noticed that by using the UDP length field, I could do a significant optimization when reading incoming datagrams. > > For example, if the UDP length was 8284 bytes, it was a very good guess that the arriving packet had an NFS header of 92 bytes and a data field of 8192 bytes. The same information would have been available in the IP header, e.g., if IHL=5 (typically), then if IPlength were 8304, you?d have the same hint. Esp. given that UDP packets where (UDPlen != (IPlen - 4*IHL)) are more recent (Teredo extensions starting 2008, UDP options starting 2015) than when Auspex went defunct (2003). Joe From cabo at tzi.org Sat Nov 28 22:21:22 2020 From: cabo at tzi.org (Carsten Bormann) Date: Sun, 29 Nov 2020 07:21:22 +0100 Subject: [ih] UDP Length Field? In-Reply-To: References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> <1606628663.gado418l8gsg80wg@hostingemail.digitalspace.net> Message-ID: <582027D6-38D2-4829-A4E2-657194484223@tzi.org> On 2020-11-29, at 07:14, Joseph Touch via Internet-history wrote: > > The same information would have been available in the IP header, e.g., if IHL=5 (typically), then if IPlength were 8304, you?d have the same hint. Except that NFS packets are typically fragmented. Gr??e, Carsten From vint at google.com Sun Nov 29 04:33:00 2020 From: vint at google.com (Vint Cerf) Date: Sun, 29 Nov 2020 07:33:00 -0500 Subject: [ih] UDP Length Field? In-Reply-To: <96e68aae-1f98-b62a-626e-3100f55869cb@gmail.com> References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> <96e68aae-1f98-b62a-626e-3100f55869cb@gmail.com> Message-ID: the primary proponents of splitting off IP from TCP were Jon Postel, Danny Cohen and David Reed, I believe. Sadly, Jon and Danny are no longer with us. My recollection is primarily that UDP was to allow for real-time, non-retransmitted, non-sequenced delivery for voice, video, radar in which low latency was more important than sequenced and assured delivery. As to the length field, it may merely have been habit to include, even if the value could have been computed. Sometimes was used to distinguish real data from padding to achieve preferred word boundaries. v On Sat, Nov 28, 2020 at 8:21 PM Brian E Carpenter via Internet-history < internet-history at elists.isoc.org> wrote: > Reverse designing it (a bit like reverse engineering), it seems useful > to be able to check that the intended payload length fits inside the > actual packet length. If it doesn't, you are exposed to what you might > call buffer underrun issues. Conversely, if you don't like covert channels, > you might want to detect any spare bits after the payload. > > Regards > Brian Carpenter > > On 29-Nov-20 12:42, Timothy J. Salo via Internet-history wrote: > > Hi, > > > > Can anyone provide some [historical] insight into why the UDP header > > contains a length field? TCP manages to ascertain the length of data in > > a packet just fine without a length field, so why couldn't UDP? > > > > Several people have noted that the UDP length field is redundant, > > including for example, the current Internet Draft "Transport Options for > > UDP", > > . > > > > There are some other opinions, some of which sound to me like > > after-the-fact reasoning: > > > > - So that UDP can run over network protocols other than IP (although > > presumably TCP could do this just fine without a length field). But, > > the UDP spec says that an IP-like pseudo header needs to be created, > > in any case. > > > > - Layering and encapsulation reasons, (although, again, TCP seems like > > a counter example). > > > > - Word alignment, (there were 16-bits left over, so why not use it for > > the length?). Personally, this sounds the most likely to me. > > > > Thanks, > > > > -tjs > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > -- Please send any postal/overnight deliveries to: Vint Cerf 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From jnc at mercury.lcs.mit.edu Sun Nov 29 04:46:42 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 29 Nov 2020 07:46:42 -0500 (EST) Subject: [ih] UDP Length Field? Message-ID: <20201129124642.83CC718C091@mercury.lcs.mit.edu> > From: "Timothy J. Salo > Can anyone provide some [historical] insight into why the UDP header > contains a length field? I would echo the suggestion to ask Deve Reed directly. I don't recall any discussion of the point at the time - I suspect it just wasn't an important question at the time - something to remember; the role of chance in design. (Oh, if you reach out to him, you could also ask why the 'no checksum' value is '0', and not '-1' - remember that if present, the checksum field contains the complement of the sum, and since 0 is an 'impossible' value for the sum, -1 is the _inherent_ 'impossible' checksum field value. Using '0' for 'none' requires an extra step in the computation, since -1 [0 when complemented] is a legitimate possible sum value. At least, I think I have that correct; the brain is fading.) > Word alignment, (there were 16-bits left over, so why not use it for > the length?). I suspect that, plus i) belt and suspenders robustness - if the UDP length is not <= the length as given by the IP header, there's an error; and ii) Vint's point that one can pad to achieve even word length. (I wonder what TCP does for that, without a length field? I guess it doesn't.) Although of course when TCP and UDP were defined there were a lot of machines that had 36-bit words, so padding was more useful then. Noel From craig at tereschau.net Sun Nov 29 06:47:37 2020 From: craig at tereschau.net (Craig Partridge) Date: Sun, 29 Nov 2020 07:47:37 -0700 Subject: [ih] UDP Length Field? In-Reply-To: References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> <96e68aae-1f98-b62a-626e-3100f55869cb@gmail.com> Message-ID: I remember asking Danny Cohen the question about the UDP length decades ago and for the life of me, I can't recall the answer. It was about the time I was trying to learn the origins of UDP, which per Vint's note, created in a hallway discussion among Jon Postel, Danny Cohen and Dave Reed, at a TCP group meeting, I think in '78 or '79. Recall that the creation of UDP meant TCP and IP had to be split apart, so a distinct TCP was evolving concurrently with UDP in a very short time. I'm hoping Dave remembers details. Craig On Sun, Nov 29, 2020 at 5:33 AM Vint Cerf via Internet-history < internet-history at elists.isoc.org> wrote: > the primary proponents of splitting off IP from TCP were Jon Postel, Danny > Cohen and David Reed, I believe. Sadly, Jon and Danny are no longer with > us. My recollection is primarily that UDP was to allow for real-time, > non-retransmitted, non-sequenced delivery for voice, video, radar in which > low latency was more important than sequenced and assured delivery. As to > the length field, it may merely have been habit to include, even if the > value could have been computed. Sometimes was used to distinguish > real data from padding to achieve preferred word boundaries. > > v > > > On Sat, Nov 28, 2020 at 8:21 PM Brian E Carpenter via Internet-history < > internet-history at elists.isoc.org> wrote: > > > Reverse designing it (a bit like reverse engineering), it seems useful > > to be able to check that the intended payload length fits inside the > > actual packet length. If it doesn't, you are exposed to what you might > > call buffer underrun issues. Conversely, if you don't like covert > channels, > > you might want to detect any spare bits after the payload. > > > > Regards > > Brian Carpenter > > > > On 29-Nov-20 12:42, Timothy J. Salo via Internet-history wrote: > > > Hi, > > > > > > Can anyone provide some [historical] insight into why the UDP header > > > contains a length field? TCP manages to ascertain the length of data > in > > > a packet just fine without a length field, so why couldn't UDP? > > > > > > Several people have noted that the UDP length field is redundant, > > > including for example, the current Internet Draft "Transport Options > for > > > UDP", > > > . > > > > > > There are some other opinions, some of which sound to me like > > > after-the-fact reasoning: > > > > > > - So that UDP can run over network protocols other than IP (although > > > presumably TCP could do this just fine without a length field). > But, > > > the UDP spec says that an IP-like pseudo header needs to be created, > > > in any case. > > > > > > - Layering and encapsulation reasons, (although, again, TCP seems like > > > a counter example). > > > > > > - Word alignment, (there were 16-bits left over, so why not use it for > > > the length?). Personally, this sounds the most likely to me. > > > > > > Thanks, > > > > > > -tjs > > > > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > -- > Please send any postal/overnight deliveries to: > Vint Cerf > 1435 Woodhurst Blvd > McLean, VA 22102 > 703-448-0965 > > until further notice > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > -- ***** Craig Partridge's email account for professional society activities and mailing lists. From vgcerf at gmail.com Sun Nov 29 06:58:41 2020 From: vgcerf at gmail.com (vinton cerf) Date: Sun, 29 Nov 2020 09:58:41 -0500 Subject: [ih] UDP Length Field? In-Reply-To: References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> <96e68aae-1f98-b62a-626e-3100f55869cb@gmail.com> Message-ID: 1977 - about TCP 3 time... v On Sun, Nov 29, 2020 at 9:48 AM Craig Partridge via Internet-history < internet-history at elists.isoc.org> wrote: > I remember asking Danny Cohen the question about the UDP length decades ago > and for the life of me, I can't recall the answer. It was about the time I > was trying to learn the origins of UDP, which per Vint's note, created in a > hallway discussion among Jon Postel, Danny Cohen and Dave Reed, at a TCP > group meeting, I think in '78 or '79. > > Recall that the creation of UDP meant TCP and IP had to be split apart, so > a distinct TCP was evolving concurrently with UDP in a very short time. > > I'm hoping Dave remembers details. > > Craig > > > On Sun, Nov 29, 2020 at 5:33 AM Vint Cerf via Internet-history < > internet-history at elists.isoc.org> wrote: > > > the primary proponents of splitting off IP from TCP were Jon Postel, > Danny > > Cohen and David Reed, I believe. Sadly, Jon and Danny are no longer with > > us. My recollection is primarily that UDP was to allow for real-time, > > non-retransmitted, non-sequenced delivery for voice, video, radar in > which > > low latency was more important than sequenced and assured delivery. As to > > the length field, it may merely have been habit to include, even if the > > value could have been computed. Sometimes was used to > distinguish > > real data from padding to achieve preferred word boundaries. > > > > v > > > > > > On Sat, Nov 28, 2020 at 8:21 PM Brian E Carpenter via Internet-history < > > internet-history at elists.isoc.org> wrote: > > > > > Reverse designing it (a bit like reverse engineering), it seems useful > > > to be able to check that the intended payload length fits inside the > > > actual packet length. If it doesn't, you are exposed to what you might > > > call buffer underrun issues. Conversely, if you don't like covert > > channels, > > > you might want to detect any spare bits after the payload. > > > > > > Regards > > > Brian Carpenter > > > > > > On 29-Nov-20 12:42, Timothy J. Salo via Internet-history wrote: > > > > Hi, > > > > > > > > Can anyone provide some [historical] insight into why the UDP header > > > > contains a length field? TCP manages to ascertain the length of data > > in > > > > a packet just fine without a length field, so why couldn't UDP? > > > > > > > > Several people have noted that the UDP length field is redundant, > > > > including for example, the current Internet Draft "Transport Options > > for > > > > UDP", > > > > >. > > > > > > > > There are some other opinions, some of which sound to me like > > > > after-the-fact reasoning: > > > > > > > > - So that UDP can run over network protocols other than IP (although > > > > presumably TCP could do this just fine without a length field). > > But, > > > > the UDP spec says that an IP-like pseudo header needs to be > created, > > > > in any case. > > > > > > > > - Layering and encapsulation reasons, (although, again, TCP seems > like > > > > a counter example). > > > > > > > > - Word alignment, (there were 16-bits left over, so why not use it > for > > > > the length?). Personally, this sounds the most likely to me. > > > > > > > > Thanks, > > > > > > > > -tjs > > > > > > > -- > > > Internet-history mailing list > > > Internet-history at elists.isoc.org > > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > > > > > -- > > Please send any postal/overnight deliveries to: > > Vint Cerf > > 1435 Woodhurst Blvd > > McLean, VA 22102 > > 703-448-0965 > > > > until further notice > > -- > > Internet-history mailing list > > Internet-history at elists.isoc.org > > https://elists.isoc.org/mailman/listinfo/internet-history > > > > > -- > ***** > Craig Partridge's email account for professional society activities and > mailing lists. > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > From jnc at mercury.lcs.mit.edu Sun Nov 29 10:45:56 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 29 Nov 2020 13:45:56 -0500 (EST) Subject: [ih] UDP Length Field? Message-ID: <20201129184556.AE26A18C091@mercury.lcs.mit.edu> > From: Craig Partridge > Recall that the creation of UDP meant TCP and IP had to be split apart No. The TCP/IP split _long_ predates the creation of UDP. The former is already apparent as of IEN-21, "TCP 3 Specification" (see pages 56 and 59 for the IP and TCP header formats), from January 1978. UDP is IEN-71, from 21-Jan-79 (and as I recall, there was not a lengthy discussion before it came out). Oh, looking at IEN-71, in the packet format description, it says "data, padded with zero octets at the end to make a multiple of two octets". So Vint's comment about the length was right on target. It mentions host name lookup (_not_ DNS; it was servers which had a copy of the host table) as the intended appplication. Time was also early, IIRC. My recollection is that TFTP was the first non-datagra protocol (i.e. not single-packet transactions) to make use of UDP, but my memory mmay be failing me there. Noel From vint at google.com Sun Nov 29 11:28:51 2020 From: vint at google.com (Vint Cerf) Date: Sun, 29 Nov 2020 14:28:51 -0500 Subject: [ih] UDP Length Field? In-Reply-To: <20201129184556.AE26A18C091@mercury.lcs.mit.edu> References: <20201129184556.AE26A18C091@mercury.lcs.mit.edu> Message-ID: Noel, yes, we did the split to support real-time and then concluded that UDP was the best way to present the "service" vs running over raw IP. v On Sun, Nov 29, 2020 at 1:46 PM Noel Chiappa via Internet-history < internet-history at elists.isoc.org> wrote: > > From: Craig Partridge > > > Recall that the creation of UDP meant TCP and IP had to be split > apart > > No. The TCP/IP split _long_ predates the creation of UDP. The former is > already apparent as of IEN-21, "TCP 3 Specification" (see pages 56 and 59 > for > the IP and TCP header formats), from January 1978. UDP is IEN-71, from > 21-Jan-79 (and as I recall, there was not a lengthy discussion before it > came > out). > > Oh, looking at IEN-71, in the packet format description, it says "data, > padded > with zero octets at the end to make a multiple of two octets". So Vint's > comment > about the length was right on target. > > It mentions host name lookup (_not_ DNS; it was servers which had a copy of > the host table) as the intended appplication. Time was also early, IIRC. My > recollection is that TFTP was the first non-datagra protocol (i.e. not > single-packet transactions) to make use of UDP, but my memory mmay be > failing > me there. > > Noel > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > -- Please send any postal/overnight deliveries to: Vint Cerf 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice From touch at strayalpha.com Sun Nov 29 11:36:01 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sun, 29 Nov 2020 11:36:01 -0800 Subject: [ih] UDP Length Field? In-Reply-To: <20201129124642.83CC718C091@mercury.lcs.mit.edu> References: <20201129124642.83CC718C091@mercury.lcs.mit.edu> Message-ID: <655C357E-8B6D-42E4-AE9F-4941DBE5D06E@strayalpha.com> Hi, Noel (et al.), > On Nov 29, 2020, at 4:46 AM, Noel Chiappa via Internet-history wrote: > > (Oh, if you reach out to him, you could also ask why the 'no checksum' value > is '0', and not '-1' -1 is a valid number in one?s complement (1111 1111 1111 1110) -1 in 2?s complement is 1111 1111 1111 1111 and is -0 in 1?s complement notation > - remember that if present, the checksum field contains > the complement of the sum, and since 0 is an 'impossible' value for the sum, Either 0 or -0 could come up as a valid 1?s complement sum over the words; the Internet checksum is simply defined as ?if either 0 or -0 comes up, use -0 as the inserted checksum?, i.e., it uses the complement of the one?s complement sum only when that sum is 0. That?s just a choice, It could easily have been made the other way - but there is one small difference (see below). > -1 is the _inherent_ 'impossible' checksum field value. -1 in 1?s complement is a valid checksum; only ?0? is declared ?impossible? by fiat (not by a property of the number space), because it is used to indicate no-checksum. > Using '0' for 'none' > requires an extra step in the computation, since -1 [0 when complemented] is a > legitimate possible sum value. At least, I think I have that correct; the > brain is fading.) There are the following possibilities: (assume the packet are is block zeroed less expensively than per-word zeroing) A. if you declare 0 as no-checksum, checksummed packets it would need to correct the final sum before inserting it non-checksummed packets do nothing B, if you declare -1 as no-checksum, checksummed packets it would need to correct the final sum before inserting it non-checksummed packets need to insert -0 C. if you allow 0 and -0 as valid checksums all packets need to be checksummed, but no final step is needed to adjust So if you want to reduce work for the non-checksummed packets, ?B? is the choice. Joe From touch at strayalpha.com Sun Nov 29 11:42:27 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sun, 29 Nov 2020 11:42:27 -0800 Subject: [ih] UDP Length Field? In-Reply-To: <20201129124642.83CC718C091@mercury.lcs.mit.edu> References: <20201129124642.83CC718C091@mercury.lcs.mit.edu> Message-ID: Hi, Noel (et al.), > On Nov 29, 2020, at 4:46 AM, Noel Chiappa via Internet-history wrote: > > I suspect that, plus i) belt and suspenders robustness - if the UDP length is > not <= the length as given by the IP header, there's an error; TCP would have needed that too - esp. given it is intended to be more robust AND the checksum isn?t affected by zero-padding. > and ii) Vint's > point that one can pad to achieve even word length. (I wonder what TCP does > for that, without a length field? I guess it doesn't.) This makes more sense to me, as it would allow use of machine word size padding for UDP packets, but assume that TCP did its own data-padding (sending machine wordsize segments) for all except open/close. I.e., it would reduce UDP processing overhead by allowing machine size transfers all the time - that seems very useful when doing realtime (as was its initial motivation). Joe From jnc at mercury.lcs.mit.edu Sun Nov 29 13:15:26 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 29 Nov 2020 16:15:26 -0500 (EST) Subject: [ih] UDP checksums (Was: UDP Length Field?) Message-ID: <20201129211526.E6E1018C091@mercury.lcs.mit.edu> > From: Joseph Touch > Either 0 or -0 could come up as a valid 1's complement sum over the > words Perhaps I'm confused, but I don't see how you could get 0 (i.e. all 0 bits) as a 1's complement sum from anything except a 'packet' containing nothing but 0's, i.e. no valid packet (and from that observation, _if correct_, the rest of my prior comment flows). Here's my thinking about 'no 0 sum'; if I've somehow blown it, I would appreciate having my error pointed out! (Truly! :-) Consider the computation of the partial 1's complement S, Sn, for words 0-n. It's Sn-1+ Wn (word n) = PSn (partial sum) + Cn (carry). Cn is then added to PSn to produce Sn. The only way for Sn to be 0 is either a) for PSn to be -1, and Cn to be 1; or b) for PSn to be 0, and Cn to be 0. The latter I think can only happen in the degenerate case I mentioned to start with: numbers Sn-1 and Wn can only produce a PSn of 0 either if i) both are 0 (the degenerate case), or ii) they are two numbers that sum to 0 - but that will produce a carry, so Cn will be 1 - so there is no ii). As to the first possibility (PSn to be -1, and Cn to be 1), there's no way to get that, I think: e.g. if Sn-1 is -1, and Wn is -1, then Cn will be 1, but PSn will be -2. Any other values for Sn-1 and Wn will also produce values for PSn and Cn which are not -1 and 1. I think? Noel From karl at cavebear.com Sun Nov 29 13:55:56 2020 From: karl at cavebear.com (Karl Auerbach) Date: Sun, 29 Nov 2020 13:55:56 -0800 Subject: [ih] UDP Length Field? In-Reply-To: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> Message-ID: I've often myself wondered why we have redundant length information at various layers. I understand the desire to have layers be independent (an issue that I think needs some revisiting - I'll get back to that later). One problem that I've come across in my development of test software is that lengths at different layers can be inconsistent. For example, it is not uncommon (in fact for short IP packets it is necessary) for an IP packet to be shorter than the data space in an Ethernet frame. This is also true of ARP packets - they don't fill an entire Ethernet frame.? (FTP Software used this difference:? They used the gap between the end of the ARP packet [or some other short broadcast IP packet] and the end of the enclosing Ethernet frame as a place to hold license information so that they could test for duplicated/copied licenses.) One test that I often run is to re-encapsulate shorter-than maximum Ethernet frame sized IP packets into Ethernet frames that have extra space at the end.? That trips-up implementations that lazily use the Ethernet length to imply IP length.? A surprising number of implementations fail. -- Regarding TCP length (or lack of).? TCP carries a stream, not demarcated messages.? A lot of implementations implicitly depend on the happenstance that quite often every send() call or implied Push by a TCP sender sender results in a single read() completion at the receiver. ? Code that does that is potentially brittle. And as the world evolves to have more application level proxies that chain multiple TCP connections together, especially as the pieces have different MTUs and segment sizes (or there is an intermediary path between proxies that isn't IP based at all), we may see more of this kind of code begin to wobble in unpleasant ways. -- Regarding split of IP from the once monolithic TCP:? That idea seems to have surfaced in several places at different times.? For instance, when I was working on security protocols back in the 1970s at SDC Dave Kaufman and I wanted to insert end-to-end cryptographic machinery into the then still academic TCP.? Our idea was somewhat like IPSEC in that we wanted to do encryption on? IP datagrams.? That implied cracking open TCP so that there would be an explicit boundary/API to a lower layer that moved datagrams bearing IP addresses.?? This was circa 1974/75.? Vint had a hand in this.? (For us that API layer was very real - it was actual hardware, very special hardware, between TCP and the underlying IP.) But like much of what we did on that project (including my security kernel and capability architecture machine work), it was wrapped in layers of US military security and cold-war paranoia and only the thinnest glimmers of it ever made it into the public view.? (I'm particularly bothered that my work on debugging secure code, especially on a capability architecture system, has vanished.) -- I mentioned that I think we may have gone too far in protocol layer isolation.?? Layering of protocols and abstractions is good and lets us wrap our minds around? designs. But I've long wondered about what we can learn from biology. Living things are surprisingly robust. And here's where I'm going to get really fuzzy and wave my hands a lot.... One of the ways that living things manage themselves is through feedback loops that exist between seemingly independent pieces. For example, one of our reactions to infection is to increase our body temperature.? Many of these feedback loops are created through sequences of one chemical reaction triggering another triggering another.? That chain was built via evolutionary processes that did not particularly care that the indicator-chemical was from a system that was in another logical layer or abstraction. When I was doing network video back in the mid 1990's we had an issue - sometimes network conditions could not sustain a viable high quality video stream.? There needed to be a feedback loop so that sender could adjust.? Fortunately people like Steve Casner had recognized this need and created a feedback protocol into the media distribution protocol. We have some similar feedback systems in the Internet - for example TCP congestion detection can result in TCP senders decreasing their rate of transmission.? And the Explicit Congestion machinery can cross protocol layers so that routers can provide information that IP and TCP can use to change their behavior. We can go further down this path. Those of us who are managing their intake of sugars know that there are a couple of measures of importance - instantaneous blood sugar level and an measurement known as A1C.? The latter is a longer-term measure.? It is a measure of chemistry that results from longer term and slower reactions based on instantaneous blood sugar. The Internet has many of those kinds of instantaneous data generators - video rendering gear (such as Roku boxes) know when network input is underrunning their video renderers and generating bad images for viewers.? Zoom can tell when network jitter has risen to the level that speech is breaking up. But what happens to that data?? Usually nothing.? And if anything that reaction is usually confined, because of the concept of protocol layering, to the protocol and devices directly involved. In a biological sense that is like saying "every cell is on its own,? it must defend itself".? In living things that would probably lead to evolutionary extinction. Here's where I'm going to get really vague.? (Brian Carpenter sent me some materials in which it appears that he and others have done work that helps remove some of this vagueness.) I'm intrigued by the idea of network pheromones and other cross-boundary (protocol layer boundary, inter-device boundary) signals that can be used by feedback mechanisms (usually not even designed yet) to change? the larger system behavior of the Internet or local pieces of the Internet. We've seen a bit of that - Google has done some impressive work generating things like disease transmission maps based on derivations from large numbers of (at first glance) unrelated data points, such as web search queries and geo-IP data. When I was thinking about this stuff during my time at Cisco I came to know that this was an idea fraught with dangers.? Feedback systems can destroy as much as they can heal:? A high fever that the body creates to fight infection could itself kill the entire body.??? And floods of network status information can overwhelm the net - and create means for delving for information that ought not to be exposed, or create means to inject trouble into a network. ??? ??? --karl-- From dhc at dcrocker.net Sun Nov 29 15:03:25 2020 From: dhc at dcrocker.net (Dave Crocker) Date: Sun, 29 Nov 2020 15:03:25 -0800 Subject: [ih] UDP Length Field? In-Reply-To: References: <6ff008e5-4216-a02f-10b5-22434bf1b860@saloits.com> Message-ID: <6ef00f31-1b56-f096-bcac-07ae415553f2@dcrocker.net> On 11/29/2020 1:55 PM, Karl Auerbach via Internet-history wrote: > I've often myself wondered why we have redundant length information at > various layers. Arpanet: Trust the network for reliability. Trust the network for accuracy (such as getting you to the right address.) Internet: not so much. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From salo at saloits.com Sun Nov 29 16:30:18 2020 From: salo at saloits.com (Timothy J. Salo) Date: Sun, 29 Nov 2020 18:30:18 -0600 Subject: [ih] UDP Length Field? In-Reply-To: <20201129184556.AE26A18C091@mercury.lcs.mit.edu> References: <20201129184556.AE26A18C091@mercury.lcs.mit.edu> Message-ID: On 11/29/2020 12:45 PM, Noel Chiappa via Internet-history wrote: > [...] > Oh, looking at IEN-71, in the packet format description, it says "data, padded > with zero octets at the end to make a multiple of two octets". So Vint's comment > about the length was right on target. > [...] Actually, I don't think that this is describing the packet format. Rather, this specifies how to compute the checksum when the data is an odd number of bytes long. Here is more context from IEN 71 for the text quoted above: Fields ... Length is the length in octets of the data of the datagram. Checksum is the 16-bit one's complement of the one's complement sum of the parts of the internet header involved in the TCP checksum, the fields above, and the data, padded with zero octets at the end to make a multiple of two octets. So, again, I read this to say that the zero padding is only associated with checksum calculation. This doesn't not seem to suggest (to me) that the data itself (in the actual packet) is padded to an even number of bytes. It doesn't appear to me that this text justifies the need for a length field in the UDP header. Of course, there might be other justifications that I don't know about. -tjs From touch at strayalpha.com Sun Nov 29 16:44:25 2020 From: touch at strayalpha.com (Joseph Touch) Date: Sun, 29 Nov 2020 16:44:25 -0800 Subject: [ih] UDP checksums (Was: UDP Length Field?) In-Reply-To: <20201129211526.E6E1018C091@mercury.lcs.mit.edu> References: <20201129211526.E6E1018C091@mercury.lcs.mit.edu> Message-ID: <68A46A12-A24A-4DE9-A3CF-1B052562CB2D@strayalpha.com> > On Nov 29, 2020, at 1:15 PM, Noel Chiappa wrote: > >> From: Joseph Touch > >> Either 0 or -0 could come up as a valid 1's complement sum over the >> words > > Perhaps I'm confused, but I don't see how you could get 0 (i.e. all 0 bits) as > a 1's complement sum from anything except a 'packet' containing nothing but > 0's, Yes, but... > i.e. no valid packet (and from that observation, _if correct_, the rest > of my prior comment flows). No valid IP or UDP, but that?s not the case necessarily everywhere the IP checksum is used. That?s what I was considering. > Here's my thinking about 'no 0 sum'; if I've > somehow blown it, I would appreciate having my error pointed out! (Truly! :-) The one?s complement is a ring, but as you note, 0 is a special case. Only 0 + 0 -> 0 All other additions and subtractions yeid -n..n or -0 only (including, strictly, 0 - 0). The only way you get back to 0 is multiplication (n * 0 = 0). And the sum over the data + inverted checksum is always -0 (never 0). The trick is that we don?t insert the complement of the ones complement sum. We insert that ONLY if the ones complement sum is not -0; if it is, we insert -0. However, those instructions are never given in RFC791, RFC1071; they appear only in RFC768: If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care). So - technically - the IP checksum CAN be 0 (when the ones complement sum is computed as -0, which can easily happen). That?s what I was thinking about. Joe