Subject: Re: [tcpm] [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead )

From: Yuchung Cheng <[email-masked]>
Date: Thu, 30 Mar 2017 15:16:37 -0700

regarding the question in the slide 5.
"Is immediate ACK needed for out of order segments if RACK is used ?"

The answer is both yes and no: a timely feedback is appreciated (yes). But
RACK does not need 100 DUPACKs each telling one more packet is delivered
out of order (no). In other words if the ACK is timely and precise about
the delivery process, RACK would work well (so does BBR). However this can
go terribly wrong if the middle-box sends only the last ACK/SACK. It has
happened in one major cloud platform.

On Thu, Mar 30, 2017 at 2:14 PM, Michael Welzl <[email-masked]> wrote:

> Hi,
>
> Thanks Ingemar for your interesting presentation today:
> https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-s
> essb-7-transport-protocol-feedback-overhead-issues-and-solutions-00.pdf
>
> I wanted to share with you, and the list, that David Ros  (one of the
> original authors of ACK-CC, RFC 5690) and I once advised a master student
> to:
> - implement ACK-CC
> - test it
> - analyze all RFC 2119 - style keywords in RFC 5690, to see how they
> should be changed (if at all) in a possible update
>
> Back then, our thinking was that we could write a paper about it, and try
> to get this deployed as a way of doing the Experiment and moving this to PS
> status.
> However, we were less and less sure about the real value of this - whether
> actual networks need this? Then, we had less and less time available and at
> some point dropped the ball.
> I of course found it interesting to hear that it *is* a real problem, even
> today.
>
> Anyway: this master thesis is available here:
> http://heim.ifi.uio.no/michawe/teaching/dipls/marius-olsen/
> mastersthesis-mariusno.pdf
> and I think I can safely say on behalf of David, Marius (the master
> student who did this) and myself that we’re happy if someone picks this up
> and continues the work.
> It would require some digging, but I might also still have the code lying
> around somewhere - for some outdated version of Linux…
>
> Cheers,
> Michael
>
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 31 Mar 2017 17:35:12 +0000

Thanks for the details. It may be the case that it can be tricky to get a decent understanding of what is possible in terms of ACK rate reduction for TCP. The middlebox behavior to discard everything except the last ACK has also been proposed in the RAN2 WG in 3GPP.

/Ingemar

From: Yuchung Cheng [mailto:[email-masked]]
Sent: den 31 mars 2017 00:17
To: Michael Welzl <[email-masked]>
Cc: Ingemar Johansson S <[email-masked]>; tsvwg IETF list <[email-masked]>; [email-masked] Extensions <[email-masked]>
Subject: Re: [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead )

The answer is both yes and no: a timely feedback is appreciated (yes). But RACK does not need 100 DUPACKs each telling one more packet is delivered out of order (no). In other words if the ACK is timely and precise about the delivery process, RACK would work well (so does BBR). However this can go terribly wrong if the middle-box sends only the last ACK/SACK. It has happened in one major cloud platform.

On Thu, Mar 30, 2017 at 2:14 PM, Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks Ingemar for your interesting presentation today:
https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-sessb-7-transport-protocol-feedback-overhead-issues-and-solutions-00.pdf

I wanted to share with you, and the list, that David Ros  (one of the original authors of ACK-CC, RFC 5690) and I once advised a master student to:
- implement ACK-CC
- test it
- analyze all RFC 2119 - style keywords in RFC 5690, to see how they should be changed (if at all) in a possible update

Back then, our thinking was that we could write a paper about it, and try to get this deployed as a way of doing the Experiment and moving this to PS status.
However, we were less and less sure about the real value of this - whether actual networks need this? Then, we had less and less time available and at some point dropped the ball.
I of course found it interesting to hear that it *is* a real problem, even today.

Anyway: this master thesis is available here:  http://heim.ifi.uio.no/michawe/teaching/dipls/marius-olsen/mastersthesis-mariusno.pdf
and I think I can safely say on behalf of David, Marius (the master student who did this) and myself that we’re happy if someone picks this up and continues the work.
It would require some digging, but I might also still have the code lying around somewhere - for some outdated version of Linux…

Cheers,
Michael