[LOOPS] Fwd: Re: Relevant to Loops?

[Bob Briscoe <[e-mail]>]

Carsten,

I see that you're presenting the slot in loops on related work.
Below I've digested a conversation I've been having with Michael Welzl 
listing work that should be useful to loops.


-------- Forwarded Message --------
Subject: 	Re: Relevant to Loops?
Date: 	Sat, 20 Jul 2019 11:25:56 +0100
From: 	Bob Briscoe <[e-mail]>
To: 	Michael Welzl <[e-mail]>



Michael,

On 19/07/2019 08:17, Michael Welzl wrote:
> Hi,
>
>
>> On Jul 18, 2019, at 5:21 PM, Bob Briscoe <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Michael,
>>
>> I only scanned the drafts, so I've not quite grocked what "the 
>> proposed mechanism" is - the descriptions seem quite abstract.
>
> Understood; I guess it’s good to be somewhat abstract at this early 
> stage. Also, there isn’t one single proposed mechanism - the one in 
> the appendix is quite different from the rest: no need to tunnel (use 
> a hash instead), and never delay packets (just to re-sequence them). A 
> “LOOPS egress” could just ACK the hashes, and the “LOOPS ingress” 
> would retransmit packets from its cache.
>
>
>> So, I just offer the stuff below as a stream of consciousness, in 
>> case it's relevant:
>>
>>   * There's an analysis of when it becomes more efficient to
>>     retransmit locally than e2e, dependent on loss level, in Short
>>     Messages  (Damon Wischik)
>>
> I knew about the short messages work, but it has moved so far back in 
> my mind that I didn’t think of its relevance for LOOPS.
I think it's very relevant. Even if the calculation has to be adapted 
(e.g. I don't think it takes account of the processing on the link 
receiver), it gives a good structure for the optimization.
It's in S.3.b) of Short Messages 
<https://www.cl.cam.ac.uk/~djw1005/Research/ucl_research/shortmsg.pdf>.

The optimization is between processing load of the retransmitting 
machine vs. completion time (of short messages) in the common case, 
assuming the usual distribution of mice vs elephants seen on the 
Internet. The result determines at what level of loss it becomes worth 
all the bother of maintaining all the machinery and state to retransmit 
over the local link.
>>
>>   * The PWE protocol (and some other encaps) already has a seq no, so
>>     OE to OE loss can be detected.
>>
> Ok… but note my point above about tunneling
OK, I've read appx B.1 
<https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#appendix-B.1> 
now.
I like the hash idea.

But, where a protocol already has the facilities, using them improves 
performance, given network nodes sometimes need to shave every last 
per-packet op...

I assume you're aware of tunnel congestion feedback 
<https://tools.ietf.org/html/draft-ietf-tsvwg-tunnel-congestion-feedback>, 
which is already a tsvwg WG draft (it was originally based on a tunnel 
alternative in an expired ConEx draft 
<https://tools.ietf.org/html/draft-briscoe-conex-data-centre-02#section-5.1.1>). 
TCF has to count bytes to work out loss levels over the tunnel, so it's 
already half way to loops, and retrans info from loops would give TCF 
loss level for free.

However, I guess retrans info (e.g. hashes) is heavier than just a 
couple of counters. The TCF authors defined an IPFIX f/b channel (at my 
suggestion), which made sense 'cos it was only sending counters, so you 
could run it over a partially reliable SCTP transport.

Therefore, on reflection, I think there's still a place for separate 
approaches for just congestion f/b and for retransmission f/b.

Indeed, combining two of the above, the f/b protocol would have to 
determine the loss level all the time (using TCF). Then when loss was 
high, it could switch to retransmission (or FEC) mode.


>
>>   * Is Magnus Austrheim's thesis relevant? It shows how you can relax
>>     the ordering requirement for 'link' layer retransmissions, where
>>     'link' includes overlays. Unfortunately, the evaluation
>>     tantalizingly ends abruptly ('cos Magnus wanted to focus on his
>>     new job).
>>
Implementing immediate forwarding for 4G in a network simulator 
<https://www.duo.uio.no/handle/10852/68158>
>>
> Thanks for the pointers!
He ended with this odd result where, with RACK and the LTE receiving 
node not doing resequencing, completion times were generally worse. We 
couldn't work out how spurious retransmissions could make that much 
difference.

But then Joakim remembered that RACK starts in 3-DUPACK mode. So we 
surmised that the RACK flow was dropping out of SS early. Some day, I'll 
find some way to finish that off by trying to improve the start-up 
behaviour of RACK - or if anyone else on this list wants to - feel free.



Bob


>
> Cheers,
> Michael
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/