Re: QUIC and router Nat support and

Gyan Mishra <hayabusagsm@gmail.com> Mon, 06 January 2020 23:25 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AEF120041 for <quic@ietfa.amsl.com>; Mon, 6 Jan 2020 15:25:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Afe8dcsZrEIv for <quic@ietfa.amsl.com>; Mon, 6 Jan 2020 15:25:41 -0800 (PST)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2352C12007C for <quic@ietf.org>; Mon, 6 Jan 2020 15:25:41 -0800 (PST)
Received: by mail-qv1-xf35.google.com with SMTP id dp13so19803091qvb.7 for <quic@ietf.org>; Mon, 06 Jan 2020 15:25:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=/dRBJaVYJcsjh63LcQKC8V+3FT44EWs3BEAMYTbmX+0=; b=qltacW+zU7fayw+0eMwu9teHuLH+ANkvUKHO4a3dYtIsraiWDP23IDrEnVLkcOnaGW VLD/Z5lJsmtjH0hLXfArorPryKywpEzVaScwsXIAeMzvVU+AMen64O9Rg/tvV2xJXUaP QQQRDs1Fowf99gnqpn4ZqXQQ0JlBiefwcGCSekIO3LU+k+bMLhvrHojDh28RO4C70Uds T6MTz+2rFS3zUWcoZaAVS1RTfzKHpm9VBj7ch7ZE0B/4/3pw+5qluO5IiJKbr3565khm 5PSB8xVWPPVKUbaXrtLUDz82M+Wvlkpd2PdN74fjlPJ/KofDWxhpPA5X/flLLwT9HzTb dVrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=/dRBJaVYJcsjh63LcQKC8V+3FT44EWs3BEAMYTbmX+0=; b=Vzr0T06VyKb6n/M4LKOrYAao7tt8VjoNCCQI8JuF2C+43bDC07ERQmQJgfzGv7DieL PLqLPXHmaXUaWnthyk5eaAHx7MLvItRKJLNaoRi7t9FPev3qgsfcRbelMC6msLMUIl/k yaY4/i006tjgLJHXQRQx8Qs2ywoUoPAAfkR1LcTz7JoS1cK0/yMlwr0cy3Xkb6UWVX4o wJ43nqpjsfu/lprUxhu/Dm49RXPdxlIYE/sbab8Mp12u0h/Awyl6BAI5+6PQVVoKgbjO x0XzNc4TzOfwWGYjmbI4keibir2YXtF7SvoLCmnSn0dZ02DtQZHj0+C1hsh8Bm1JpVdE Zf4g==
X-Gm-Message-State: APjAAAV3ZuMdxV1xkdOeBy1RpGmLTKBcU3SifQ12k6Lhis+UI64W6yu4 Kr/o/Djxq38jRjRXwOEl3jVCytEScF8=
X-Google-Smtp-Source: APXvYqxf6yjPJgskhhbIujrUQz89/I36SNqs4WJupIQHquLTn1G3eVyuYOKLSSmKpHxv6E9ksz1toA==
X-Received: by 2002:ad4:4f94:: with SMTP id em20mr78396044qvb.95.1578353139992; Mon, 06 Jan 2020 15:25:39 -0800 (PST)
Received: from ?IPv6:2600:1003:b104:3309:adf3:1833:a2ef:bd0f? ([2600:1003:b104:3309:adf3:1833:a2ef:bd0f]) by smtp.gmail.com with ESMTPSA id k184sm21705590qke.2.2020.01.06.15.25.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jan 2020 15:25:39 -0800 (PST)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Google-Original-From: Gyan Mishra <hayabusaGSM@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-FFEC7E68-687E-4523-8A8F-8DD8C53FBB04"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: QUIC and router Nat support and
Date: Mon, 06 Jan 2020 18:25:38 -0500
Message-Id: <2F1BB899-05DE-41BB-8332-DB74C693652F@gmail.com>
References: <DA030E02-7041-4BB3-B7AC-AB489F10D52A@ericsson.com>
Cc: IETF QUIC WG <quic@ietf.org>
In-Reply-To: <DA030E02-7041-4BB3-B7AC-AB489F10D52A@ericsson.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
X-Mailer: iPhone Mail (17C54)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ldJf7_PSI_3CfAju-26WfKZJ3Jc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2020 23:25:43 -0000

Great!!

Thank you 

Kind regards,

Gyan

Sent from my iPhone

> On Jan 6, 2020, at 6:29 AM, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> wrote:
> 
> 
> Hi Gyan,
> 
> We have a document on manageability that should cover most of the points you raised below:
> 
> https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/
> 
> There is also an open issue on GitHub regarding NAT support which explicitly say that CID should not be used for NAT. Short time-outs are actually not a problem if a CID is used from the endpoint that is NATed as address migration is supported by Quic. 
> 
> https://github.com/quicwg/ops-drafts/issues/87
> 
> If you have further points that should be covered by this document but are currently not, please feel free to raise another issue on GitHub!
> 
> Mirja
> 
> 
>>> Am 04.01.2020 um 17:38 schrieb Gyan Mishra <hayabusagsm@gmail.com>:
>>> 
>> 
>> QUIC WG,
>> 
>> I have a few questions related to QUIC and network support for NAT and also with out of order packets as well as other network related issues in supporting QUIC over UDP.
>> 
>> Routers today do not support QUIC for Nat and treat the connections as traditional udp and may not have the proper long lived timers as tcp. 
>> 
>> Most router vendors have global timeouts for Nat but and the setting are global for all tcp and udp.
>> 
>> Since QUIC used udp and is long lived connections how do you break that out of the generic udp timer..
>> 
>> It sounds like routers need special treatment like a NAT ALG to support QUIC.
>> 
>> As far as routing with ECMP paths since QUIC is udp based has that could cause issues with out of sequence packets.
>> 
>> I believe load balancing may also be an issue and how is that addressed since QUIC used udp and really the LB appliances now need to support the QUIC protocol to monitor state of the connections.
>> 
>> From a routing and QOS perspective there also could be issue with WRED which is used to prevent saw tooth effect ramp up and down tcp globalization ; since QUIC uses udp wred will not work.
>> 
>> 
>> Is their any development in the routing or internet WGs related to support of QUIC from a routing and switching perspective?
>> 
>> Kind regards,
>> 
>> Gyan
>> Verizon Communications 
>> Cell 301 502-1347
>> -- 
>> Gyan S. Mishra
>> 
>> IT Network Engineering & Technology 
>> 
>> Verizon Communications Inc. (VZ)
>> 
>> 13101 Columbia Pike FDC1 3rd Floor
>> 
>> Silver Spring, MD 20904
>> 
>> United States
>> 
>> Phone: 301 502-1347
>> 
>> Email: gyan.s.mishra@verizon.com
>> 
>> www.linkedin.com/in/networking-technologies-consultant
>> 
>>