Re: [tsvwg] [LOOPS] FW: New Version Notification for draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt

["Zhouxingwang (Joe)" <[e-mail]>]

Hi, 

One challenge LOOPS is facing is whether to perform local recovery when packet loss happens, and whether to relay the signal of loss event to TCP (via marking ECN) to reduce sending rate after local recovery performed. LOOPS may borrow end host's current transport layer idea to do congestion detection via local measurement, like RTT variation, packet loss rate, goodput, etc,. Once LOOPS got the congestion information then it will be helpful for handling the challenge.

Tunnel-Congestion-Feedback provides LOOPS a straight forward way to do this. If CE marking does not happen but packet loss happens, LOOPS may perform local recovery safely, otherwise LOOPS should relay the signal of loss event to TCP to reduce its sending rate. To relay such a signal, when retransmission is used for local recovery mechanism, tunnel egress node may choose not to ask the ingress node to do retransmission; when FEC is used, egress node may choose not to recover the lost packet when e2e is non-ECT or choose to recovery the loss packets and mark CE bit of it when e2e is ECT.

To me, for LOOPS, it looks like carrying this information from egress to ingress may not be necessary when retransmission is used. The egress may decide by itself whether to ask for a retransmission by controlling how to acknowledge the received packets. It may pretend a packet has been received to ingress so that the ingress does not retransmit it. 

If FEC is used, carrying this information from tunnel egress back to ingress seems helpful. Anyone could point out any existing examples on how the FEC can possibly react on such information (may not be limited to information mentioned by this draft, but also other information like segment RTT, goodput, loss rate, etc)?

Thanks
Joe

-----Original Message-----
From: Weixinpeng (Jackie) [mailto:[e-mail]] 
Sent: Monday, May 06, 2019 10:40 AM
To: [e-mail]
Cc: [e-mail]
Subject: [LOOPS] FW: New Version Notification for draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt

Hi,

We are reactivating the following document as it has been found out useful for some ongoing work, i.e. https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-ecn-support/  and LOOPS (Localized Optimization of Path Segments).

I cc'ed to LOOPS mailing list as I think this mechanism provides supplementary information about the tunnel  (path segment in LOOPS terminology)  congestion level which might benefit LOOPS to determine if a local recovery is necessary and if a loss signal should be relayed back to end host sender further.  With LOOPS, it can be used together with segment based local RTT measurement information.  Normally CE marking should happen before a real packet loss if congestion occurs. So when there is a loss detected but with low CE marking ratio, local recovery is reasonable to be performed and signal of a loss event may not be necessarily relayed to end host sender to trigger window reduction. 
If FEC is used, this information would be useful for tunnel FEC parameter settings, such as the number of symbols in a source block and number of repair packets. It might be worth noting that a rate limiter at tunnel ingress would be required to avoid overshooting if congestion occurs.

Currently we are using IPFIX to carry back the information from tunnel egress to ingress. LOOPS guys may want to use some other encapsulations. You are welcome to bring it up.

Thanks,
- Xinpeng 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, May 06, 2019 10:18 AM
To: Liyizhou <[e-mail]>; Sami Boutros <[e-mail]>; Weixinpeng (Jackie) <[e-mail]>; Liang Geng <[e-mail]>; Liyizhou <[e-mail]>
Subject: New Version Notification for draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt


A new version of I-D, draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt
has been successfully submitted by Yizhou Li and posted to the IETF repository.

Name:		draft-ietf-tsvwg-tunnel-congestion-feedback
Revision:	07
Title:		Tunnel Congestion Feedback
Document date:	2019-05-06
Group:		tsvwg
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tsvwg-tunnel-congestion-feedback/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tsvwg-tunnel-congestion-feedback-07
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-tunnel-congestion-feedback
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-tunnel-congestion-feedback-07

Abstract:
   This document describes a method to measure congestion on a tunnel
   segment based on recommendations from RFC 6040, "Tunneling of
   Explicit Congestion Notification", and to use IPFIX to communicate
   the congestion measurements from the tunnel's egress to a controller
   which can respond by modifying the traffic control policies at the
   tunnel's ingress.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat