Re: [AVTCORE] IP address/port number handling in "RTP-in-QUIC" encapsulation layer

Colin Perkins <csp@csperkins.org> Thu, 12 May 2022 12:08 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA090C157B56 for <avt@ietfa.amsl.com>; Thu, 12 May 2022 05:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=csperkins.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SNoLMKxrLwx for <avt@ietfa.amsl.com>; Thu, 12 May 2022 05:08:40 -0700 (PDT)
Received: from mx2.mythic-beasts.com (mx2.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F744C14F736 for <avt@ietf.org>; Thu, 12 May 2022 05:08:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=ZHoH4dG4CApiKbs7NKPiu7WOYXB0kPnKElYMzm2vPR8=; b=fNgaBmTBIg4EFGyGtUv+9UAg4Z 4FDRFKgd1yP/CablyjY/GRUYjFq6BUrMGziDTXrwXBrkqTQq5E5ME1yfYnUh/JAMEAWgswgeN08+C F4MlGeP1ftiwDqywViyaStYAKXaIREiWNOhcjvmF5hb1iCNBOr6Tn5huK7OigfRwY7CwOJl0liBVm Mhu9b1g6yUMzhi94JgLGz2/af+Bp76cMXefMjXDng7AiKqd7ygy2Ocd3aFdoGVGmDTlE5TCnX93yJ yG18/lN7vftnztT8l0R9KniBqVsYj0W/X8JKeUaBNiIu7NVrHLz+pwYD7b4YqDkZ1q6ZPY5KYh6r8 0jJZfI8g==;
Received: from [81.187.2.149] (port=37437 helo=[192.168.0.67]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1np7cO-000127-20; Thu, 12 May 2022 13:08:38 +0100
From: Colin Perkins <csp@csperkins.org>
Message-Id: <6A469FF3-F4F8-49BE-840C-C7FB7F3DDB18@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E8608E3F-6885-4279-B3CE-4386934AED84"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Thu, 12 May 2022 13:08:28 +0100
In-Reply-To: <CAKKJt-cqGP8cFPrZAa4k1kb2HYceRvK7vrzwTAGOyCy6Xdu20w@mail.gmail.com>
Cc: IETF AVTCore WG <avt@ietf.org>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
References: <CAKKJt-cqGP8cFPrZAa4k1kb2HYceRvK7vrzwTAGOyCy6Xdu20w@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.21)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/jHvHMk3ShOJjnkKUqjjwfQXmuiw>
Subject: Re: [AVTCORE] IP address/port number handling in "RTP-in-QUIC" encapsulation layer
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2022 12:08:44 -0000

Hi,

I’d argue that RTP doesn’t care about IP addresses and ports; it just needs a way of separating out traffic intended for different sessions. The signalling cares.

Colin



> On 12 May 2022, at 00:35, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> We've had some pretty interesting observations in https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/4 <https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/4> about our observation that RTP/RTCP knows about IP addresses and  port numbers, but QUIC applications only use IP addresses and port numbers when establishing connections, and after that, QUIC applications are using connection IDs, even if underlying IP addresses change because of NAT rebinding or the QUIC implementation itself performs connection migration. 
> 
> This is obviously part of a larger question about RTP-in-QUIC encapsulation layer functionality, but it's interesting now, because 
> if an encapsulation layer can handle all the vagaries of ports and IP addresses, the application doesn't have to
> if an application is talking to a single IP address/port number, the encapsulation layer can continue to present that interface to the application, no matter what else happens below the encapsulation layer.
> If the IP address/port numbers are "virtual", the underlying IP addresses need not even be the same IP address family. If an application thinks it's talking to an IPv4 endpoint even if the underlying network supports IPv6, this could remove some impediments to IPv6 migration. 
> If the QUIC connection ID is the same for all the m=lines, this might provide bundling functionality as well. 
> Obviously, this will require more thought (Suhas suggested "design session" in one of the comments), but does it seem interesting and/or useful?
> 
> Best,
> 
> Spencer
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt