Re: [LOOPS] Other WGs/RGs (Re: LOOPS meetings in May 2020, replacing IETF 107 side meetings)

[Carsten Bormann <[e-mail]>]

Hi Yizhou,

Thank you for the quick response.
Let me pick up some of the items below for tomorrow’s call, giving them numbers 1 to 6 so we can build a more detailed agenda around them:

> On 2020-05-06, at 11:15, Liyizhou <[e-mail]> wrote:
> 
> Hi Carsten,
> 
> That is a pretty complete list. Thanks for putting them together.
> 
> Please see inlines with [yz].
> 
> Yizhou
> 
> * Name: TCPM
> * Work: RACK
> * Issue in other group: (from draft-ietf-tcpm-rack-08:) ... develop a
>   new TCP loss detection algorithm called RACK ("Recent
>   ACKnowledgment").  RACK uses the notion of time, instead of packet
>   or sequence counts, to detect losses, for modern TCP
>   implementations that can support per-packet timestamps and the
>   selective acknowledgment (SACK) option.  It is intended to be an
>   alternative to the DUPACK threshold approach [RFC6675] ...
> * **Issue in LOOPS**: Does LOOPS need to rely on a sequence-preserving
>  path for efficient loss detection, or can we use some of the RACK
>  work for more time-based loss detection?  How do we translate the
>  TCP features used by RACK into features that are available in LOOPS?
> * Type: Watch, potentially Import
> 
> [yz] 
> Sequence number based loss detection is easier for LOOPS segment. LOOPS ingress does not rely on ACK clocking, so egress may generate less ACKs if everything is ok. Time-based loss detection would require more precise RTT monitoring which need quite frequent ACKs. So time-based loss detection may put a requirement on frequency/number of ACK generations. 
> 
> When a LOOPS segment has a severe packet re-ordering which confuses with packet loss, time-based loss detection is good to be employed.
> 
> There is another issue to be considered in LOOPS related to RACK. When interacting with RACK based end host sender, LOOPS egress has loose requirement to maintain the packet order when waiting for the lost packet to be recovered over the LOOPS segment.
> 
> [/yz]

I think that is a great summary of a few of the technical points we should discuss tomorrow:

(1) Should we simply assume that reordering in the LOOPS segment is unlikely, so we only have to specify the DUPACK style of loss detection within LOOPS?
(2) What can we find out about the end-to-end transports contributing to a LOOPS-enhanced flow (e.g., are they RACK—based?), so we can adapt behavior appropriately?  (This assumes some minority traffic might be negatively impacted.  It also violates the “don’t peek” principle.)

> ---
> 
> * Name: MASQUE (WG to be, recent BOF 2020-03-24)
> * Work: Embedding proxied flows into QUIC and HTTP/3
> * Issue in other group: "Congestion Control over Congestion Control in
>  case of UDP or IP proxying", i.e., when the proxied flows are UDP or
>  IP (~ VPN), the interaction between end-to-end transport protocol
>  control loops (congestion control) and the control loops run by QUIC
> * **Issue in LOOPS**: Does LOOPS need to perform specific work to mitigate
>  issues stemming from nested congestion control?  Note that the LOOPS
>  segment is typically, but not always, significantly shorter than the
>  end-to-end path, which might be similar in a MASQUE situation.
> * Type: Watch
> 
> [yz]
> Currently LOOPS ingress from my understanding does not intend to do sending rate adjustment. The control is at the end host sender. LOOPS tries to do the minimum set of work in participating in the congestion control, i.e. via CE-marking.

(3) Yes, and I think it is worth to explicitly confirm that this is the way we are going.

> If a full-function nested control loop (including sending rate adjustment at LOOPS ingress) in LOOPS is required, some active interaction between the end host and the LOOPS ingress node would be required. I do not think this is for the initial stage of LOOPS. We'd better start from the simple approach.

Right.  MASQUE has the benefit that, in the forward direction, the end host is part of the inner segment that is happening within QUIC.  But we don’t know how they will use that benefit, and what they will do for the reverse direction (which will often be the direction with the larger amount of traffic).   So that is why this just says “watch”.

> I did not follow MASQUE very closely, but it seems working between the sender and the proxy. Potentially would give us some hints on advanced features to be considered at LOOPS later stage.    
> [/yz]

Agree.

> ---
> 
> * Name: IPPM, TSVWG
> * Work: Formats and algorithms for measurement
> * **Issue in LOOPS**: What IPPM-defined formats and algorithms for
>  measurement can we usefully import into the LOOPS measurement system
> * Type: potentially Import
> * To do: What came out of the
>  draft-ietf-tsvwg-tunnel-congestion-feedback work?
> [yz]
> IPPM-defined ioam format intends to help network oam.  It puts a lot of effort in its trace option (pre-allocated trace and incremental trace). It is quite obvious that trace option is not appropriate for LOOPS since LOOPS would work on tunnel endpoints. No intermediate node’s information is required. If ioam edge-to-edge mode is to be used, then ioam edges have to happen to be LOOPS segment ingress and egress. 

(4) That is my evaluation as well.  We should check whether there is agreement on this.

> So I would not think ioam can be directly used for LOOPS segment. The most important information for LOOPS is timestamps in my understanding. We may re-use its format but put it in LOOPS header. That makes the design clearer.  
> [/yz]

(5) Timestamp formats are one thing we can copy from IPPM, where we need to have timestamps where ingress and egress agree about the format.  There is also the question whether we want to use data formats defined for IPFIX, and/or measurement protocols such as OWAMP, TWAMP.

> ---
> 
> * Name: NVO3, INTAREA, SPRING/6MAN
> * Work: Tunnel encapsulation formats
> * **Issue in LOOPS**: We need to follow the homes of tunneling protocols
>  to which bindings are being defined, which depending on the choices
>  of the WG may include NVO3 (Geneve), intarea (GUE), spring/6man
>  (SRv6).
> * Type: Import
> * To do: There is no obvious home for GRE at this point, but GRE is
>  another obvious choice for a tunneling protocol.
> 
> [yz]
> Agreed that GRE is a choice here.
> [/yz]

(6) We may want to write up a straw man (and then need to find someone familiar with GRE and its real-world incarnation).

> ---
> 
> * Name: DETNET, RAW
> * Work: DETNET data plane, RAW, PREOF
> * Issue in other group: Define a data plane (encapsulation) for
>  replicating, eliminating duplicates, and potentially reordering
>  traffic (PREOF).
>  RAW extends this work to wireless networks.
> * **Issue in LOOPS**: Can we integrate some of this work for
>  retransmission and reconstruction?
> * Type: Watch, potentially import
> * **Issue in LOOPS**: Potentially (long term): Can we make some of the
>  LOOPS components available in a way that is useful for DETNET and RAW?
> * Type: Export
> [yz]
> DETNET looks having an assumption that an end-to-end retransmission in case of a packet loss would make the packet miss its cycle and become useless in industrial networking.
> A (shorter) segment based retransmission or FEC might be able to make the recovered packet keep up with the cycle? 
> That's an interesting thought :)
> [/yz-end]

This is a bit hard to frame into a discussion point right now, but we should be talking to DETNET and RAW people about reconstruction (FEC) and retransmission.  The latter is maybe a bit less “deterministic”, but might still make the latency goal.  I don’t think we know enough to go into a technical discussion of this tomorrow.

See you all in 17¼ hours…

Grüße, Carsten