Re: [tsvwg] Network feedback and security (was: New Version Notification for draft-huang-tsvwg-transport-challenges-00.txt)

[Tom Herbert <[e-mail]>]

On Thu, Oct 19, 2023 at 12:28 AM Sebastian Moeller <[e-mail]> wrote:
>
> Hi Ingemar,
>
> On 19 October 2023 07:19:40 CEST, Ingemar Johansson S <[e-mail]> wrote:
> >Hi
> >
> >I have followed this discussi a bit. I focus only on the congestion indication and the discussion around the multi-bit congestion signaling.
> >
> >L4S is just recently standardized and we have just starated to get the community onboard to implement and evaluate it on a larger scale.
> >We should give it some time and get more data before we jump on the next big thing.
> >
> >It is of course possible for IETF to start working on the next big thing with multi-bit congestion indication. But as I see it, we currently have more than enough tasks on the table with L4S.
>
> [SM] Respectfully, that task is clearly on the proponents of L4S and IMHO should have been done before granting RFC status. L4S already hindered one higher resolution ECN approach (SCE) without actual evidence of superiority, let's leave it at that one victim please.
> In my opinion L4S is too little too late, as we already know multi-bit per packet information is superior, so we arguably should focus on that.

Sebastian,

There's a fundamental problem with mulit-bit per packet information:
there's no place in packets to put the data that will work across the
Internet! (other than the eight bit TOS/Priority field). The correct
mechanism for network to hosts signaling is Hop-by-Hop options but
those currently see a 99% drop rate. There are proposed alternatives
like putting information in transport payload, TCP and now UDP
options, overloading flow label or IPv6 addresses; but all of these
have drawbacks that will preclude widescale deployment (these are
discussed in section 5 of draft-herbert-host2netsig). Since network to
host signaling modifies data in flight limits the solution space even
more, for instance it might be okay for a switch to read a transport
payload like QUIC spin bit, but writing data in the transport payload
risks systematic data corruption.

I agree that multi-bit data should facilitate more precise congestion
control with faster reaction time, but I also think we need that more
in the data center than over the Internet and the problem of defining
a multi-bit packet field for the data is solvable in a limited domain.

Tom

>
> Regards
>          Sebastian
>
>
> >
> >/Ingemar
> >
> >
> >> -----Original Message-----
> >> From: tsvwg <[e-mail]> On Behalf Of Christian Huitema
> >> Sent: Tuesday, 17 October 2023 17:28
> >> To: Sebastian Moeller <[e-mail]>; [e-mail]
> >> Cc: [e-mail]
> >> Subject: [tsvwg] Network feedback and security (was: New Version
> >> Notification for draft-huang-tsvwg-transport-challenges-00.txt)
> >>
> >>
> >> On 10/17/2023 3:17 AM, Sebastian Moeller wrote:
> >> > Personally, ever since I read Arslan, Serhat, and Nick McKeown.
> >> ‘Switches Know the Exact Amount of Congestion’. In Proceedings of the
> >> 2019 Workshop on Buffer Sizing, 1–6, 2019. I came to the prediction that
> >> something like max(bufferoccupancy) over a network path in either
> >> predicted sojourntime or percentual buffer filling could really improve
> >> congestion control if included in all packets. That paper and follow ups
> >> on that idea are to my quite convincing. I see no real security concern
> >> as the network node adding this information might as well have dropped
> >> the packet if it wanted to harm that flow, so little increase in attack
> >> surface in that direction. What I hope something like this might allow
> >> is a gentler exist from slow start (assuming one can measure and compare
> >> the dynamics of the congestion indicator with those of the slow-starting
> >> flow to predict when to exist slow start without first having to dump ~2
> >> too much data into the network in one RTT). The network could indirectly
> >> profit if end-points use this information to better reign in congestion
> >> pro-actively, but that clearly is not guaranteed, especially over the
> >> open internet.
> >>
> >> Yes, network feedback is useful. You mention "max(bufferoccupancy) over
> >> a network path" as a signal, but I would argue that ECN is pretty much a
> >> 1 bit version of exactly that. So your argument is really for "more ECN
> >> bits". That's plausible, but the whole "L4S/Prague" effort seems to
> >> indicate that 1 bit is enough, because you can observe that bit on many
> >> consecutive packets. The conservative side of me would say we should
> >> first deploy the 1 bit version, and then study whether we really need
> >> many more bits.
> >>
> >> The "gentler exit from slow start" issue is largely addressed by
> >> Hystart, which uses the variations of the RTT as a signal. And yes,
> >> Hystart can be improved by also monitoring the ECN bits, not just the
> >> RTT.
> >>
> >> But there are in fact security concerns. We already know about ICMP
> >> attacks in which attackers spoof the network feedback and inject fake
> >> ICMP packets, for example to disrupt PMTU discovery. "Man on the side"
> >> attackers can easily send a second copy of a packet with modified header
> >> bits and race it to the destination. If transports accept that copy as
> >> genuine, they will heed the faked congestion signals and the attacker
> >> will succeed in disrupting the connection.
> >>
> >> -- Christian Huitema
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>