Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room

[dropping NWCRG and DTN to reduce noise a bit]


Hi,

Yes, Linux TCP has indeed been quite robust to re-ordering for many years, see here for a quite detailed study:
https://www.duo.uio.no/handle/10852/9034 <https://www.duo.uio.no/handle/10852/9034>

Cheers,
Michael


> On Jan 6, 2020, at 9:47 AM, Zhouxingwang (Joe) <zhouxingwang@huawei.com> wrote:
> 
> Hi,
> 
> It seems Linux TCP is much more out-of-order tolerant than we think.
> 
> 1) TCP can dynamically adjust flow reordering level, not stick to 3. (https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt)
> tcp_reordering - INTEGER Initial reordering level of packets in a TCP stream.
> 	TCP stack can then dynamically adjust flow reordering level
> 	between this initial value and tcp_max_reordering
> 	Default: 3
> tcp_max_reordering - INTEGER Maximal reordering level of packets in a TCP stream. 300 is a fairly conservative value, but you might increase it
> 	if paths are using per packet load balancing (like bonding rr mode) Default: 300
> 
> 2) RACK has been enabled by default in Linux for loss detection since kernel4.4. (https://kernelnewbies.org/Linux_4.4) 
> tcp_recovery - INTEGER
> 	This value is a bitmap to enable various experimental loss recovery
> 	features.
> 
> 	RACK: 0x1 enables the RACK loss detection for fast detection of lost
> 	      retransmissions and tail drops. It also subsumes and disables
> 	      RFC6675 recovery for SACK connections.
> 	RACK: 0x2 makes RACK's reordering window static (min_rtt/4).
> 	RACK: 0x4 disables RACK's DUPACK threshold heuristic
> 
> 	Default: 0x1
> 
> The retransmission conflict between TCP and other layer will not be a big issue.
> 
> Thanks
> Joe
> 
> -----Original Message-----
> From: nwcrg [mailto:nwcrg-bounces@irtf.org] On Behalf Of Stuart William Card
> Sent: Monday, January 06, 2020 9:46 AM
> To: Carsten Bormann <cabo@tzi.org>
> Cc: nwcrg@irtf.org; loops@ietf.org; dtn@ietf.org
> Subject: Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
> 
> Carsten --
> 
> Thanks for your thoughtful response. I'll try to focus my inputs. :-)
> 
>> ...
>> (1) ... more intricate (and timely) knowledge of the critical path
> segment...
>> (2) techniques such as TCP splitting allowed mitigating some...
>> of the latency induced performance issues end-to-end protocols exhibited...
>> With increasing use of encryption... (2) is going away...
>> (1) will stay relevant... where that knowledge can be provided...
>> What LOOPS is trying to do is providing a protocol that can help even 
>> in the absence of both (1) and (2)...
>> recovering packets can lead to reordering...
>> applications will need to be part of the picture...
>> LOOPS itself will need to focus on a more narrow set of problems and 
>> opportunities, and this is the time to discuss whether we got that 
>> narrowing right in the current charter proposal...
> 
> Agreed. Further, not only transport but also network layer encryption kills simple approaches to (2), leaving AFAIK only multipath or trading increased mean latency to reduce latency variance.
> 
> Many of us have suffered from suboptimal and sometimes unanticipated interactions between link and transport layer behaviors (retransmission in both, flow control in the data link, congestion control in the transport).
> Application layer adaptive behaviors (e.g. video streaming that switches dynamically during a session among different source coding rates based upon end to end performance as it varies) further complicate this. LOOPS will be yet another interacting control loop. In the worst case, a non-congestion loss of a link layer frame could lead to:
> - data link retransmission
> - LOOPS retransmission
> - transport retransmission
> - transport backoff
> - application rate downshift
> All at once! Presumably we can't prevent this altogether but want to minimize its occurrence.
> 
> The charter looks good. I suggest broadening its scope of consideration of cross-layer interactions: not just w/transport congestion control, but also w/retransmission, misordering & resequencing at all layers.
> 
> --
> Stuart W. Card, VP & Chief Scientist
> Critical Technologies Inc. (CTI)
> <stu.card@critical.com>
> 
> 
> _______________________________________________
> nwcrg mailing list
> nwcrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nwcrg
> 
> -- 
> LOOPS mailing list
> LOOPS@ietf.org
> https://www.ietf.org/mailman/listinfo/loops