Subject: [LOOPS] FW: New Version Notification for draft-amend-iccrg-multipath-reordering-00.txt

From: <[email-masked]>
Date: Fri, 10 Jul 2020 08:43:27 +0000

Dear all,

I want to announce the availability of a new draft addressing the challenge of packet reordering due to multipath. This draft includes countermeasures like resequencing, recovery and retranmission techniques, still on headline level. The draft is placed at ICCRG.

Even if Carsten already informed me, that multipath is not in scope initialy at LOOPS, I could imagine that some of the techniques in the draft are covered by your proposed charter https://github.com/loops-wg/charter.

Please feel free to give me feedback and/or contribute.

Btw. congestion control issues, adressed by your charter, I assume those to be mainly CC in CC, right? https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00  and e.g. QUIC MASQUE have similar challenges.

Br

Markus

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Mittwoch, 8. Juli 2020 20:05
> To: von Hugo, Dirk <[email-masked]>; von Hugo, Dirk <Dirk.von-
> [email-masked]>; Amend, Markus <[email-masked]>; Amend,
> Markus <[email-masked]>
> Subject: New Version Notification for draft-amend-iccrg-multipath-reordering-
> 00.txt
> 
> 
> A new version of I-D, draft-amend-iccrg-multipath-reordering-00.txt
> has been successfully submitted by Markus Amend and posted to the
> IETF repository.
> 
> Name:		draft-amend-iccrg-multipath-reordering
> Revision:	00
> Title:		Multipath sequence maintenance
> Document date:	2020-07-07
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-amend-iccrg-multipath-
> reordering-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-amend-iccrg-multipath-
> reordering/
> Htmlized:       https://tools.ietf.org/html/draft-amend-iccrg-multipath-reordering-
> 00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-amend-iccrg-multipath-
> reordering
> 
> 
> Abstract:
>    This document discusses the issue of packet re-ordering which occurs
>    as a specific problem in multi-path connections without reliable
>    transport protocols such as TCP.  The topic is relevant for devices
>    connected via multiple accesses technologies towards the network as
>    is foreseen e.g. within Access Traffic Selection, Switching, and
>    Splitting (ATSSS) service of 3rd Generation Partnership Project
>    (3GPP) enabling fixed mobile converged (FMC) scenario.
> 
> 
> 
> 
> 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
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 10 Jul 2020 12:31:41 +0200

Hi Markus,

> Even if Carsten already informed me, that multipath is not in scope initialy at LOOPS, I could imagine that some of the techniques in the draft are covered by your proposed charter https://github.c…

The resequencing part is not, as LOOPS does not resequence.

In previous discussions, we have always considered resequencing as an optional service that could be provided unilaterally at the egress (we have different experiences with and thus different opinions on resequencing).
In many cases, the data that enable recovery (retransmission or reconstruction) are all that is needed to run a (non-reliable, as needed on the IP layer) resequencing process; this would use static expiration (Section 5.3 in your draft) or adaptive expiration (Section 5.4).  The adaptation mechanisms in the latter would benefit from some measurement information being available at the egress, but that is probably already needed to control the formation of return channel information (ACKs etc.) or for reconstruction (symbol numbers for FEC).
This has always been implicit; I’m not sure we want to make supplying measurement information for a resequencing process an explicit objective.

Section 6 (recover mechanisms) of course is the essence of LOOPS.  We are not discussing the multipath aspects for the LOOPS MVP we describe in the charter, but LOOPS MVP could run either per-path or on the aggregate in a multipath environment.  I think that if a protocol for this goes forward, that could be based on LOOPS even if that doesn’t cover the multipath use case fully yet.

Grüße, Carsten