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

From: Jana Iyengar <[email-masked]>
Date: Thu, 6 Apr 2017 17:45:40 -0700

Thanks for the presentation Ingemar; unfortunately I missed this at the
IETF. As one of the authors of RFC 5690, I'm familiar with the pitfalls of
doing ack CC, but I think we may be able to get around them in QUIC since
there's explicit ack information in QUIC. We are experimenting with this in
QUIC, and we'll be happy to bring data when we have some.

On Fri, Mar 31, 2017 at 10:35 AM, Ingemar Johansson S <
[email-masked]> wrote:

> 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 )
>
>
>
> 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-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
>
>
>
>
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 7 Apr 2017 06:43:21 +0000

Hi
Thanks, looking forward to see the results of your experiments.
Important to understand is that the goal is not “reduced ACK rate at any cost”. Certain arrangements will need a higher ACK rate than others for instance depending on congestion control specifics.

But hopefully the ACK rate will decrease in a statistical sense and that is good, furthermore work on this will (possibly in an ideal world) send a signal that the ACKs that traverse the network are needed for one reason or the other and that middleboxes should not try to tamper with  these ACKs , call me a dreamer…

/Ingemar

From: Jana Iyengar [mailto:[email-masked]]
Sent: den 7 april 2017 02:46
To: Ingemar Johansson S <[email-masked]>
Cc: Yuchung Cheng <[email-masked]>; Michael Welzl <[email-masked]>; [email-masked] Extensions <[email-masked]>; tsvwg IETF list <[email-masked]>; Ian Swett <[email-masked]>
Subject: Re: [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead )

Thanks for the presentation Ingemar; unfortunately I missed this at the IETF. As one of the authors of RFC 5690, I'm familiar with the pitfalls of doing ack CC, but I think we may be able to get around them in QUIC since there's explicit ack information in QUIC. We are experimenting with this in QUIC, and we'll be happy to bring data when we have some.

On Fri, Mar 31, 2017 at 10:35 AM, Ingemar Johansson S <[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>]
Sent: den 31 mars 2017 00:17
To: Michael Welzl <[email-masked]<mailto:[email-masked]>>
Cc: Ingemar Johansson S <[email-masked]<mailto:[email-masked]>>; tsvwg IETF list <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> Extensions <[email-masked]<mailto:[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