Subject: FW: New Version Notification for draft-kuehlewind-quic-substrate-01.txt

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 8 Jul 2019 12:01:53 +0000

Hi all,

we posted an update of draft-kuehlewind-quic-substrate which some smaller edits, some more text on requirements for discovery, and a new sub use case (thanks Lucas!).

Feedback would be very welcome! Also on github here:

https://github.com/mirjak/draft-kuehlewind-quic-substrate

Mirja

On 05.07.19, 17:38, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-kuehlewind-quic-substrate-01.txt
    has been successfully submitted by Mirja Kuehlewind and posted to the
    IETF repository.
    
    Name:		draft-kuehlewind-quic-substrate
    Revision:	01
    Title:		Use Cases and Requirements for QUIC as a Substrate
    Document date:	2019-07-05
    Group:		Individual Submission
    Pages:		9
    URL:            https://www.ietf.org/internet-drafts/draft-kuehlewind-quic-substrate-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-kuehlewind-quic-substrate/
    Htmlized:       https://tools.ietf.org/html/draft-kuehlewind-quic-substrate-01
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-kuehlewind-quic-substrate
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-kuehlewind-quic-substrate-01
    
    Abstract:
       TCP is often used as a proxying or tunneling protocol.  QUIC is a
       new, emerging transport protocol and there is a similar expectation
       that it too will be used as a substrate once it is widely deployed.
       Using QUIC instead of TCP in existing scenarios will allow proxying
       and tunneling services to maintain the benefits of QUIC natively,
       without degrading the performance and security characteristics.  QUIC
       also opens up new opportunities for these services to have lower
       latency and better multistreaming support.  This document summarizes
       current and future usage scenarios to derive requirements for QUIC
       and to provide additional protocol considerations.

    
    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: Erik Sy <[email-masked]>
Date: Mon, 8 Jul 2019 14:22:46 +0200

Hi Mirja,

another use case for proxying QUIC is to speed up QUIC's connection
establishment on high-latency access networks.

An article with more details can be found
here: https://arxiv.org/pdf/1907.01291.pdf

Best regards,
Erik

---

From: Madhan Raj Kanagarathinam <[email-masked]>
Date: Mon, 08 Jul 2019 18:11:45 +0530

My current research also works 0-RTT proxification of QUIC+SOCKS. Whereas, TCP might take 4-7 RTTs.

https://github.com/quicwg/base-drafts/issues/2518

We decided to look into the proxification of QUIC later as it wasn't chartered work.

Regards,

Madhan

On 2019-6-11, at 12:28, Madhan Raj Kanagarathinam <[email-masked]> wrote:
> Thanks for looping in Lars.
> We personally see it as significant importance in QUIC because of two reason
> - Proxification of plain QUIC (non-http based) is yet to be explored and might be widely used in Smartphones (as used in MPTCP)
> - This can be used in 5G ATSSS (TR 23.793) as 0-RTT and secured convertor for enhanced resilience on network handover
> Do let me know your opinion.

those are certainly possible use cases for QUIC. However, as Mark has said, the WG at the moment is completely focused on finishing the chartered work, and we will not have time to discuss this at the meetings.

Lars

--------- Original Message ---------

Sender : Erik Sy <[email-masked]>

Date : 2019-07-08 17:53 (GMT+5:30)

Title : Re: FW: New Version Notification for draft-kuehlewind-quic-substrate-01.txt

Hi Mirja,

Best regards,
Erik

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 9 Jul 2019 11:19:02 +0100

Hi Erik,

Thanks for sharing your work. Did you compare your approach to DNS
prefetching (whether instigated by user agent heuristics or
"dns-prefetch" link relation)?

Lucas

---

From: Erik Sy <[email-masked]>
Date: Tue, 9 Jul 2019 14:15:03 +0200

Hi Lucas,

thanks for this interesting question!
Here you can find a plot with the respective behaviour similar to Figure
7 of the article: https://erik-sy.de/QuicSocks_plot.pdf
It assumes perfect DNS prefetching, thus the DNS lookup is completed
before the client starts the establishment of the QUIC connection.
Are you aware of a real-world performance evaluation of DNS prefetching?

Best regards,
Erik