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

[Brian E Carpenter <[e-mail]>]

Harald,

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
http://tools.ietf.org/html/draft-ietf-rtcweb-transports-05#section-3.5
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.

   Brian