[LOOPS] Transport recovery and interaction with, link, and LOOPS loss recovery

[Gorry Fairhurst <[e-mail]>]

Thank you for taking the trouble to update 
draft-li-tsvwg-loops-problem-opportunities, the new text does help in 
many places, and I'm sorry not to have responded earlier to this new 
text.  I am still not clear yet what is antcipated from the transport 
congestion-control response. Please see comments below:

(1) Moving figure 1 seems helpful to introduce the context. Thanlks.

(2) In Section 6: I read section 6 as describing two recovery cases: One 
is about DupACK-based recovery. The other says it is about RACK 
recovery, I wonder if this is mainly the case where the dupACK, where I 
think this is about TLP (which uses RACKL) to short-cut the RTO by 
trying to recover after ~2RTTs?

(3) I think the text suggests these might have different implications on 
LOOPS, which seems reasonable, although I have questions:

“If LOOPS network does not buffer the out-of-order packets caused
       by packet loss, TCP sender which uses a time based loss detection
       like RACK [I-D.ietf-tcpm-rack] will perform well here.  It uses
       the notion of time to replace the conventional DUPACK threshold
       approach to detect losses.  Hence it prevents the TCP sender from
       invoking fast retransmit too early. “

(4) In Section 4.1:

“When a sender does not receive an ACK for a given segment within
    a certain amount of time called retransmission timeout (RTO), it re-
    sends the segment [RFC6298].  RTO can be as long as several seconds.”
…
“Even when
    the lost packet is not an exact tail, it can possibly add another RTT
    because there may not be enough packets in flight to trigger the fast
    retransmit).”

- I think this text argues simply for TLP?

- How would the method imporve performance, if TLP were to be widely 
deployed, since it's been promoted for TCP and specified for QUIC?


(5) Also, maybe I misunderstand, can’t RACK trigger retransmission 
earlier than timeout for a TLP - which the start of the ID said was an 
important use-case?

“Local retransmission will not
       interfere the sender's retransmission generally in this case.  If
       time based loss detection is not supported at the sender, end to
       end retransmission may be invoked as usual.  It consumes extra
       bandwidth Because the lost packets (i.e. recovered packet) is
       normally a very small percentage of the total packets.  Then extra
       bandwidth cost is not significant.”
- I don’t really understand this argument. Is this saying there will be 
few losses, and hence the additional capacity used by retransmission is 
small. If that was my correct interpretation, how does LOOPS know there 
are few losses? Does it measure this and rate-control it’s 
retransmissions to ensure this, or maybe some other method is used to 
avoid there being significant load from two levels of retransmission?

(6) Is some sort of check needed anyway perhaps? Because LOOPS could 
potentially work over a path with L2 retransmissions (e.g. WiFi, and any 
loops retransmissions multiply the number of L2 retransmissions?
- Can LOOPS be tunnelled over LOOPS in any cases?

(7) I now think I might understand the scope of the proposed work is 
constrained only to cases where ECN has been deployed and is enabled 
end-to-end. In Section 5.2:


“LOOPS can CE(Congestion Experienced) marks
    its recovered packets as the loss signal to end-to-end. Converting a
    packet loss signal to CE marking signal brings the benefits of
    reducing Head-of-Line blocking and probability of RTO expiry
    [RFC8087] without affecting TCP sender's loss based congestion
    control behaviour while enjoying the faster local recovery. ECN
    based indication is equivalent to a loss event at the TCP sender
    [RFC3168].”
…
“ In this way, a requirement is set for applying LOOPS.”

I still think this would benefit from being clearer at the start of the 
document, because only ECT (ECN-Capable Transport) flows should be 
directed to an LOOPS enabled path segment, as I think it says?

Best wishes,

Gorry