Re: [tcpm] Long tail of TCP stacks (was: RE: draft-ietf-tcpm-accurate-ecn-24 addressingallWGLCcomments)

Hi Richard,

Yes, I had a look at ECN and SACK. As far as I can tell, a lot of "basic" IoT stacks neither support SACK nor ECN (RFC 3168), albeit it is a bit difficult to know for sure for some closed-source stacks. I have only found ECN support in the well-known "high-end" stacks that are used also for desktop and server computers.

SACK seems more prevalent than ECN, since some "basic" stacks such as lwIP support SACK (well, at least partly).

However, one interesting insight in my survey was that one open source stack has different license conditions for its SACK and its ECN code.

This could imply that some commercial IoT implementations could use the open source ECN implementation, but they may not be able to use SACK due to formal license problems.  In this specific context, it could indeed be possible that ECN (or even AccECN, if available) is supported, but not SACK. The root cause would be the difference in license conditions.

Of course, a theoretical work-around in this case would be an entire SACK implementation from scratch, but this may not be a low-hanging fruit.

As far as I understand, such a use of "ECN without SACK" would have a non-technical root cause. But this could be a real-world issue in running code...

Michael

> -----Original Message-----
> From: rs.ietf@gmx.at <rs.ietf@gmx.at>
> Sent: Wednesday, September 27, 2023 10:18 AM
> To: tcpm@ietf.org; Scharf, Michael <Michael.Scharf@hs-esslingen.de>
> Subject: Re: [tcpm] Long tail of TCP stacks (was: RE: draft-ietf-tcpm-accurate-
> ecn-24 addressingallWGLCcomments)
> 
> 
> Out of curiosity, did you investigate how many of these IoT stacks support
> ECN (negotiation, ECT-marking of sent messages, and RFC3168 ECE/CWR
> feedback)?
> 
> WOuld be interesting to see, if SACK or ECN is more prevalent in these
> implementations...
> 
> Richard
> 
> 
> 
> Am 23.09.2023 um 12:01 schrieb Scharf, Michael:
> > In don't plan to get involved into this WGLC discussion and this e-mail is not
> about AccurateECN.
> >
> > Yet, I have a general comment related to the long tail of TCP stacks...
> >
> >>> How many stacks are out there not supporting TCP SACK? How many of
> >> them will implement
> >>> ECN++?
> >>
> >> [MK5] I think tens if not hundreds, when all various devices like network
> >> printers and stacks in various IoT appliances, vehicles, etc are counted.
> >
> > [...]
> >
> > I think this number from Markku is realistic. See also RFC 9006.
> >
> > I have recently surveyed some IoT stacks. Well, there is really a large number
> of different TCP/IP stacks out there. Some only support the most basic
> standard track TCP features (if at all).
> >
> > In TCPM (and the IETF as a whole), IMHO we often focus on desktop and
> server operation systems. Yet, in IoT and some other network domains that
> increasingly get connected to the Internet, TCP/IP implementations can be
> different to what is the default in Linux, Windows, BSD, etc. I believe that, as of
> today, one cannot assume that all TCP stacks relevant for the Internet indeed
> support and enable SACK. Of course, the same applies to ECN.
> >
> > For what it is worth, one example mentioned in RFC 9006 is lwIP
> (Leightweight TCP/IP). Recent versions of lwIP support at least sending SACK
> options, but the logic is very simple (as far as I understand). As far as I can tell,
> lwIP is fairly sophisticated as compared to other IoT stacks that are much more
> rudimentary.
> >
> > Recently I tried to come up with a simple lwIP example for my students. I
> ended up creating an echo server example that runs in Linux user space:
> https://github.com/michael-scharf/lwip-echoserver
> >
> > If someone else is interested in playing with lwIP, maybe such an example
> can help...
> >
> > Michael
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm