Re: [tsvwg] MP-DCCP for UDP multipath transport

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 16 November 2020 14:59 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C2F3A1286; Mon, 16 Nov 2020 06:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.612
X-Spam-Level:
X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ld-p7SxGdMd; Mon, 16 Nov 2020 06:59:26 -0800 (PST)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD3A3A11A8; Mon, 16 Nov 2020 06:59:13 -0800 (PST)
Received: from [IPv6:2a02:8109:1140:c3d:cb2:f97b:5916:11f5] (unknown [IPv6:2a02:8109:1140:c3d:cb2:f97b:5916:11f5]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 09B9E72275404; Mon, 16 Nov 2020 15:59:10 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <LEJPR01MB063580A9B12A42F0E0559D6EFAE30@LEJPR01MB0635.DEUPRD01.PROD.OUTLOOK.DE>
Date: Mon, 16 Nov 2020 15:59:07 +0100
Cc: tsvwg@ietf.org, draft-amend-tsvwg-multipath-dccp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <61381E76-382A-427A-9F51-C0188BF24FF3@lurchi.franken.de>
References: <LEJPR01MB063580A9B12A42F0E0559D6EFAE30@LEJPR01MB0635.DEUPRD01.PROD.OUTLOOK.DE>
To: Markus.Amend@telekom.de
X-Mailer: Apple Mail (2.3654.20.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/WrBEieS9cJYqK5J6AlpI1h05XUI>
Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 14:59:30 -0000

> On 16. Nov 2020, at 13:52, Markus.Amend@telekom.de wrote:
> 
> Dear all,
>  
> as the TSVWG chairs suggested in the IETF 109 session, I continue the discussion on the mailinglist.
Hi Markus,

I have two questions:

1. You stated that you are using CCID2. This means that you are adding to handling of UDP
  packets a congestion control. How does this interact with a congestion control provided by
  the application?

2. Considering that you are fine with a tunneling protocol that provides a congestion control,
  what are the benefits of using DCCP instead of using SCTP with UDP encapsulation? You can
  use PR-SCTP with the "don't retransmit" policy and could also let the reordering done by
  SCTP. Your failover scenario should be supported by all SCTP implementations. The
  load-sharing would require some standardisation effort.

Best regards
Michael
>  
> For all who were not able to attend, the presented slides are available underhttps://datatracker.ietf.org/meeting/109/materials/slides-109-tsvwg-sessa-61-dccp-extensions-for-multipath-operation-00, with a main focus on the prototype implementation. This prototype leverages MP-DCCP between a mobile handset and a public aggregation point, for giving multipath/multi-access benefit to at least UDP traffic - complementing MPTCP - when communicating with the Internet. Due to the MP-DCCP encapsulation framework, support is not restricted to UDP and it’s even possible to provide the multipath service to IP or Ethernet traffic. Packet based scheduling, as well as flow based scheduling is in scope of the prototype/drafts and explained together with results as part of the above mentioned presentation.
>  
> Seamless handover for reliability and path/access aggregation for high speeds are supported by design, fitting for example excellently into the 3GPP ATSSS scope, leveraging:
> https://tools.ietf.org/html/draft-amend-tsvwg-multipath-dccp-03
> https://tools.ietf.org/html/draft-amend-tsvwg-multipath-framework-mpdccp-01
> https://tools.ietf.org/html/draft-amend-tsvwg-dccp-udp-header-conversion-01
>  
>  
> and general scheduling and re-ordering concepts from
> https://tools.ietf.org/html/draft-amend-iccrg-multipath-reordering-01
> https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers-01
>  
> Especially for 3GPP ATSSS purposes, this very dedicated and simple MP-DCCP framework provides an alternative over the currently discussed MP-QUIC (+DATAGRAM + MASQUE), which is from an IETF perspective much broader in scope and not dedicated to ATSSS purposes.
>  
> However MP-DCCP is not limited to ATSSS and can be applied end-to-end with or without encapsulation.
>  
> So I encourage you to read through the drafts, give feedback and discuss the potential roadmap towards WG adoption.
>  
> Br
>  
> Markus