Subject: Fwd: New Version Notification for draft-huitema-quic-mpath-req-00.txt

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Dec 2017 13:11:21 -0800

Yes, I know full well that multipath is not in scope for V1. But since
we are dabbling in connection migration anyhow, I thought we could just
as well have a document listing multipath requirements and issues...

-- Christian Huitema

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-huitema-quic-mpath-req-00.txt
Date: 	Wed, 27 Dec 2017 13:07:17 -0800
From: 	[email-masked]
To: 	Christian Huitema <[email-masked]>

A new version of I-D, draft-huitema-quic-mpath-req-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name:		draft-huitema-quic-mpath-req
Revision:	00
Title:		QUIC Multipath Requirements
Document date:	2017-12-27
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-huitema-quic-mpath-req-00.txt
Status:         https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-req/
Htmlized:       https://tools.ietf.org/html/draft-huitema-quic-mpath-req-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-huitema-quic-mpath-req-00

Abstract:
   This document describes the requirement and plausible architecture of
   QUIC multipath extensions.  While the first version of QUIC is not
   scheduled to include multipath extensions, there are risks that
   decisions made in this first version might preclude some options that
   we may later find attractive.  An early review of multipath extension
   requirements and issues should minimize that risk.

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: Yoshifumi Nishida <[email-masked]>
Date: Thu, 28 Dec 2017 02:04:28 -0800

Hi Chritian,

I think this is a useful doc, but I might want to clarify one thing in the
following text.

   Since different paths experience different network conditions, it
   follows that congestion control should be executed separately for
   each path, just like it is executed separately for each subflow in
   MPTCP [RFC6824].

MPTCP measures ACKs, losses and delays on each path, however, adjusting
transfer rate in MPTCP is governed by coupled congestion control. So, it
seems to me that this is not very precise expression for MPTCP.
I think the draft needs to clarify this point.
Also, I believe QUIC should follow the same principle.

Thanks,
--
Yoshi

On Wed, Dec 27, 2017 at 1:11 PM, Christian Huitema <[email-masked]>
wrote:

> Yes, I know full well that multipath is not in scope for V1. But since we
> are dabbling in connection migration anyhow, I thought we could just as
> well have a document listing multipath requirements and issues...
>
> -- Christian Huitema
>
>
> To: Christian Huitema <[email-masked]> <[email-masked]>
>