Stewart, Going back to my earlier note to identify the design choice: > > ... IF the DetNet service defines packet loss as a failure case, i.e., something > > that can't happen unless something in the network has actually failed and the > > preferred failure behavior is late delivery rather than non-delivery of impacted > > data, THEN TCP may be useful/appropriate. I read your note as advocating that the preferred failure behavior is non-delivery of impacted data, in which case, I would agree that TCP is not a good choice of protocol. Thanks, --David > -----Original Message----- > From: Stewart Bryant <stewart.bryant@xxxxxxxxx> > Sent: Friday, October 2, 2020 8:21 AM > To: Black, David > Cc: Stewart Bryant; Grossman, Ethan A.; secdir@xxxxxxxx; last-call@xxxxxxxx; > detnet@xxxxxxxx; draft-ietf-detnet-mpls-over-udp-ip.all@xxxxxxxx; Stephen > Farrell > Subject: Re: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp- > ip-06 > > > [EXTERNAL EMAIL] > > David > > The way that I look at it, TCP will deliver a given byte fed into its transmission > stream in its own good time, delaying that byte until all previous bytes are > delivered. It will also keep trying to deliver that byte as long as there is > connectivity between source and sink. That is a contrast with DetNet which is > looking for fast delivery with possibly some mitigation for packet loss. In such > circumstances TCP is a liability to the service that wanted deterministic > characteristics. I cannot therefore think of any good reason to pay the price of > DetNet to deliver TCP. If you do want to use a transport protocol that is more > sophisticated than UDP, then SCTP-PR is probably a better choice. > > - Stewart > > > > > On 1 Oct 2020, at 20:35, Black, David <David.Black@xxxxxxxx> wrote: > > > > Playing devil's advocate for a moment ... > > > >> I would be rather surprised if anyone tried to run a deterministic > >> application over TCP. > >> > >> TCP would undo all the temporal determinism and or course it looks > >> after packet loss. > > > > ... IF the DetNet service defines packet loss as a failure case, i.e., something > that can't happen unless something in the network has actually failed and the > preferred failure behavior is late delivery rather than non-delivery of impacted > data, THEN TCP may be useful/appropriate. OTOH, use of TCP increases the > DetNet attack surface, as (in contrast to UDP), causing a drop or otherwise > triggering retransmission becomes a way to attack the DetNet service by > increasing the amount of traffic sent into limited reserved network capacity and > also by delaying delivery of received data to the deterministic application. > > > > I've lost track of the original context, so I'm not able to suggest specific text and > where to add it or make changes. > > > > Thanks, --David > > > >> -----Original Message----- > >> From: detnet <detnet-bounces@xxxxxxxx> On Behalf Of Stewart Bryant > >> Sent: Thursday, October 1, 2020 11:12 AM > >> To: Grossman, Ethan A. > >> Cc: secdir@xxxxxxxx; last-call@xxxxxxxx; Stewart Bryant; > >> detnet@xxxxxxxx; draft- ietf-detnet-mpls-over-udp-ip.all@xxxxxxxx; > >> Stephen Farrell > >> Subject: Re: [Detnet] Secdir last call review of > >> draft-ietf-detnet-mpls-over-udp- > >> ip-06 > >> > >> > >> [EXTERNAL EMAIL] > >> > >> > >> > >>> On 24 Sep 2020, at 21:28, Grossman, Ethan A. <eagros@xxxxxxxxx> wrote: > >>> > >>> Thanks Stephen. FWIW it isn't too late to add some text to the > >>> DetNet Security > >> draft regarding DetNet over UDP, if someone can think up something > >> useful to say. I suppose one could simply mention UDP in the same > >> breath as TCP (implying that the same general security guidelines apply, if > that's our stance). > >>> Any thoughts (from anyone)? > >> > >> Ethan > >> > >> I would be rather surprised if anyone tried to run a deterministic > >> application over TCP. > >> > >> TCP would undo all the temporal determinism and or course it looks > >> after packet loss. > >> > >> - Stewart > >> > >> > >> > >> _______________________________________________ > >> detnet mailing list > >> detnet@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/detnet -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
