Re: [Dart] Protocols and port numbers (Re: RTP and non-RTP traffic on same UDP 5-tuple)

Brian E Carpenter <> Sun, 15 June 2014 20:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A2DEB1B2968 for <>; Sun, 15 Jun 2014 13:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BomJ53WPPEnI for <>; Sun, 15 Jun 2014 13:06:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 553161B296E for <>; Sun, 15 Jun 2014 13:06:45 -0700 (PDT)
Received: by with SMTP id eu11so3757071pac.33 for <>; Sun, 15 Jun 2014 13:06:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xKAnxWCAtbjigy2QuuAzHEHRKiVu/5bCNF6xFctkGTk=; b=t3Bc6+2CuNgpDJn/Pr5I3NLvdTaKkxIczG0VivpRPGa/22FBhvbjk6Vx3msvfMhMOE BESpLQGaJap6QFSIFA+q7k+5lBrEX67n9sTXMcJ+FP5dZfNaKcipaZTm9UnSg+aiwnJC LIzjS5ErI8KtkvzhEX0lAAhWDIaK4UcTc8eMat49ddW39zxLvQMJjqbUmOrjaLTLthBB TSIdfZJ4wgvJ0maswTMXkIpfU2tB0Ss/AnCEVwSRK5B5Mr4iuPBDuzXSyEeF4XvIr12v 4BQZMHSpNDBVdTN8hWZ7/M07GfYj+vvo0Q4jJ+OmqbGZSLQIrIMUEA8qxKHNPi9EOJRO pIhA==
X-Received: by with SMTP id tp6mr18754510pac.127.1402862804977; Sun, 15 Jun 2014 13:06:44 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id kq10sm14723126pbc.90.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Jun 2014 13:06:44 -0700 (PDT)
Message-ID: <>
Date: Mon, 16 Jun 2014 08:06:36 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Harald Alvestrand <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [Dart] Protocols and port numbers (Re: RTP and non-RTP traffic on same UDP 5-tuple)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 Jun 2014 20:06:54 -0000


On 15/06/2014 20:33, Harald Alvestrand wrote:
> On 06/13/2014 01:12 AM, Brian E Carpenter wrote:
>> Subject to David's comment about AF "colour" possibly being preserved, yes.
>> There is another little point though. We've been discussing port numbers
>> as though they are transport-independent. Actually, a classifier needs to
>> look at the protocol number (TCP, UDP, SCTP, DCCP etc) before it knows
>> for sure where the port numbers are. So debating this point before
>> draft-ietf-rtcweb-transports-05 is rock solid may be a little academic.
>> I don't think generic classifiers are set up for "SCTP over DTLS over ICE"
>> for example.
> As far as anything at all in RTCWEB is rock solid, the decision to use
> UDP is rock solid.
> So we can take that as a given for RTCWEB.
> (apart from the case where one uses TCP because the firewalls don't
> allow UDP...)

Ah. Now I understand better. The following comment is out of scope
for DART, but I think that draft-ietf-rtcweb-transports desparately
needs an overview section with a diagram that shows the complete
set of transport nestings. I was very confused by
and such a diagram would make it much clearer what a diffserv
classifier would see in the outermost header.

> Generic classifiers will detect the traffic as UDP, and may be able to
> tell RTP from DTLS-encapsulated data in the same way as the DTLS/RTP
> demultiplexing does it.

I expect David will agree that RFC 2983 might be worth a read, because
some of the same issues arise. I guess that if RTCweb takes over
the universe, classifiers might be updated to understand RTCweb
transport nestings, but initially you certainly can't assume that.