Subject: Re: [iccrg] [tsvwg] transport protocol feedback overhead

From: Michael Welzl <[email-masked]>
Date: Fri, 7 Apr 2017 09:44:07 +0200

All,

I'm cc'ing ICCRG because these are truly research musings IMO. Maybe, if folks agree, we can truly move this thread and drop the tsvwg list from recipients?

A thought:
One reason we didn't continue our own work on this (the master thesis I mentioned previously) was that it wasn't 100% clear to us whether this is a *real* problem - is it a problem worth solving? How often does it occur? How problematic is it?

I think Ingemar made a good point in his presentation about the problem being real. Still, often ACKs are mixed with payload traffic. Consider the following scenario:
Say, I have a thin uplink.
In parallel, I download a file, and I upload a file (just as a simple model).
Both take long, there is congestion, packets are dropped.

=> should the rate of outgoing payload be reduced, or should the ACK rate be reduced? Or both?

Given that ACKs tend to be smaller, losing too many ACKs could be quite harmful, and the Internet has survived very long without ACK rate reduction, I'd tend to think the payload should be the first to react.
So then, a scheme that changes the ACK rate could try to figure out if it truly was the ACKs that created congestion.

This could be done by checking the impact of one's actions with some heuristics. For example: if I increase the rate, does delay increase with it, and does it decrease again if I decrease the rate?
What if, different from a "normal" congestion control reaction where senders try to back off immediately upon any form of congestion indication, ACK rate reduction would do such tests for 2-3 round trips before actually backing off?  This would avoid a situation where, in my example, both the download and the upload traffic would back off together (which might be overdoing it).

Just some thoughts - as I said, research ideas.

Cheers,
Michael

> On 07 Apr 2017, at 09:12, Gengxuesong (Geng Xuesong) <[email-masked]> wrote:
> 
> Hi Ingemar,
> 
> Thank you for our response.
> It is reasonable to find a point that can reduce the ACK rate without hurting its performance, but I also wonder that whether ACK carries too much information which can be considered to give to the middlebox.
> For example the congestion notification generated in the middle box can be sent to the source directly without going through the receiver, just like QCN in Layer 2.
> I don't know whether this also belongs to the "middlebox interaction" you have mentioned : )
> 
> 
> Best Regards,
> 
> Xuesong
> 
> -----Original Message-----
> From: Ingemar Johansson S [mailto:[email-masked]] 
> Sent: Friday, April 07, 2017 2:51 PM
> To: Gengxuesong (Geng Xuesong); Bob Briscoe; tsvwg IETF list
> Subject: RE: [tsvwg] transport protocol feedback overhead
> 
> Hi
> 
> Sure, ACKs carry a lot of information, this is the strongest argument against middlebox interaction BTW. 
> Also the intention with ACK rate reduction is not "at any cost". One need to strike a balance between ACK rate and performance where the tolerance against reduced performance should be very low.
> 
> /Ingemar
> 
>> -----Original Message-----
>> From: Gengxuesong (Geng Xuesong) [mailto:[email-masked]]
>> Sent: den 6 april 2017 03:42
>> To: Bob Briscoe <[email-masked]>; Ingemar Johansson S 
>> <[email-masked]>; tsvwg IETF list <[email-masked]>
>> Subject: RE: [tsvwg] transport protocol feedback overhead
>> 
>> Hi Bob,
>> 
>> 
>> I think it is an interesting idea to solve the problem, but I wonder 
>> that whether doing this will cause other problem, because the ACK 
>> carries more information than arrival time.
>> For example if an ACK with congestion information arrives later than 
>> before, then the congestion response will be delayed either, which may 
>> do harm to the congested network.
>> 
>> 
>> Best Regards,
>> 
>> Xuesong
>> 
>> -----Original Message-----
>> From: tsvwg [mailto:[email-masked]] On Behalf Of Bob Briscoe
>> Sent: Friday, March 31, 2017 4:18 AM
>> To: Ingemar Johansson S; tsvwg IETF list
>> Subject: [tsvwg] transport protocol feedback overhead
>> 
>> Ingemar, list,
>> 
>> I seemed to get blocked from talking after I was trying to be polite - 
>> letting you finish your talk...
>> 
>> You described one problem:
>>  (A) In mobile (and other networks)  upstream ACK load is a problem.
>> 
>> There is a complementary problem too:
>> (B) Capacity variation is getting huge as radio wavelength increases. 
>> So it's useful for the sender to watch the timing of the ACKs to be 
>> able to track changes in capacity as fast as possible. It's also 
>> useful to be able to vary the spacing between the packets you send to 
>> probe for increases in capacity by watching the ACK spacing in response.
>> 
>> These two are in tension - (A) wants less ACKs, (B) wants them all.
>> 
>> A possible solution, is a data structure in a stretch ACK to be able 
>> to report the time of arrival of all the previous data packets (ie. 
>> the packets that the stretch ACK is ACKing.
>> 
>> Even tho this info will arrive at the sender later than it would have 
>> done if the ACKs had not been suppressed, as long as you are still 
>> getting a reasonable number of ACKs every RTT, it resolves the tension between A and B.
>> 
>> Thoughts?
>> Does this idea already exist?
>> 
>> 
>> 
>> Bob
>> 
>> PS. Apologies for dropping an innovative idea into a standards meeting.
>> This probably ought to be a research paper first.
>> 
>> 
>> --
>> __________________________________________________________
>> ______
>> Bob Briscoe                               http://bobbriscoe.net/
>

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 7 Apr 2017 16:39:22 +0100

Michael,

1/ Real problem?

I agree that we should first establish whether ACK load is a problem.
I was responding to Ingemar assuming he believed this was true, given 
that was his presentation.

I can understand that ACKs are not so much a problem because of the bits 
they carry. More because they consume transmission opportunities on 
wireless links. Also, because they consume processor cycles and 
interrupts on hosts (which is why ACK thinning is done in DCs).

2/ tsvwg/iccrg?

Actually, as Ingemar mentioned in his slides, this is potentially 
something to consider for AccECN, which is a WG doc in tcpm now.

It would at least be useful to consider how this timing info might be 
added later to the same AccECN TCP option. I mean, perhaps introduce a 
placeholder so that a further draft can be written later to add timing 
info to the same TCP option.

Note: AccECN is solely about ECN, whereas arrival timing info can be 
relevant irrespective of ECN support, so they might not fit well. 
However, in one respect the two functions fit together nicely because 
like the AccECN option, timing info is truly optional - feedback can 
still work (minimally) if the TCP option does not traverse a path. 
Amortizing both into one option should help deployment of both.

3/ Feedback delay

To answer Xuesong's initial point, I only proposed including timing info 
in ACKs /if/ the ACK rate needed to be reduced. Of course missing out 
some ACKs introduces a delay before another ACK arrives, and delays any 
timing info it contains. But if ACKs are going to be thinned/stretched, 
adding timing info about intervening arrivals is better than not adding 
it. If there are, say, W=100 packets in a window,:
* ACKing 1 in 2 packets causes the worst total feedback delay to be 101% 
of an RTT.
* ACKing 1 in 8 packets causes the worst total feedback delay to be 107% 
of an RTT.
More generally,
* ACKing 1 in d packets causes the worst total feedback delay to be 
1+(d-1)/W of an RTT.
Given ACK rate is generally only a problem when W is large, the extra 
delay could be of concern, but it should not be significant.

4/ Middle-to-sender feedback

Re. Xuesong's second point,... been there, doesn't work. See 
https://www.ietf.org/mail-archive/web/tsvwg/current/msg10843.html

This mode of feedback appeared on the tsvwg list in 2006, 2011, 2017... 
On this basis it should come up again in about 2023 :)

Bob

On 07/04/17 08:44, Michael Welzl wrote:
> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/