Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5764-mux-fixes-03.txt

From: [email-masked]
Date: Mon, 19 Oct 2015 15:10:40 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.

        Title           : Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)
        Authors         : Marc Petit-Huguenin
                          Gonzalo Salgueiro
	Filename        : draft-ietf-avtcore-rfc5764-mux-fixes-03.txt
	Pages           : 13
	Date            : 2015-10-19

Abstract:
   This document defines how Datagram Transport Layer Security (DTLS),
   Real-time Transport Protocol (RTP), Real-time Transport Control
   Protocol (RTCP), Session Traversal Utilities for NAT (STUN), and
   Traversal Using Relays around NAT (TURN) packets are multiplexed on a
   single receiving socket.  It overrides the guidance from SRTP
   Extension for DTLS [RFC5764], which suffered from three issues
   described and fixed in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-avtcore-rfc5764-mux-fixes-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5764-mux-fixes-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Oct 2015 12:49:29 +0200

Hi,

I have looked at the updated draft. I think you have resolved my 
previous comments, thank you. However, I still have some comments.

1. Split the introduction chapter. The introduction is much more than an 
introduction. I think the sub-sections likely belong in a new section 
after the introduction that discusses the issues and intended changes in 
depth. However, they are not introduction.

2. Section 1.3:

I still are uncertain if TURN channels needs the whole range 64 to 79. I 
think the text should be explicit about how many turn channels this 
support. So according to my math the proposed change is from 64-127 to 
64-79, i.e. the available number of channels has been reduced from 16384 
to 4096. That still a large number of channels.

What number of channels are currently used by implementations? I expect 
that to be single digit, or am I missing some use cases?

3.  Section 1.4:

I still don't see how what is written in this section results in any 
improvement. You authors have assumptions of how this needs to be 
implemented that isn't written down. Looking on this problem of 
demultiplexing I would build a table driven solution based on the 
ranges, where the packet is sent to the relevant protocol based on the 
table-lookup. If that protocol don't use that value, that will be the 
end of the road for that packet as invalid, rather than giving it to any 
other protocol. I get the impression that you want one to send the 
packet for testing by the protocols one after each other according to 
the order the protocols are listed. I still don't see that 
implementations will do that.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Oct 2015 12:09:51 -0400

> implementations will do that.

This has been my concern as well.

Look at it this way:

A natural implementation of this is via a switch statement. Each 
disjoint range of values is one case. (Detailed syntax varies by 
language.) A simple implementation of this may be implemented as a 
sequence of comparisons - a series of if/then/else such as you describe. 
a more time-optimal implementation uses a table lookup.

You shouldn't be mandating how this be implemented - only what the 
result is.

	Thanks,
	Paul

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 20 Oct 2015 17:01:00 +0000

Thanks, Magnus, for the additional comments.  We’ll attempt to address these in the next version.

Cheers,

Gonzalo

> On Oct 20, 2015, at 6:49 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 
> I have looked at the updated draft. I think you have resolved my previous comments, thank you. However, I still have some comments.
> 
> 1. Split the introduction chapter. The introduction is much more than an introduction. I think the sub-sections likely belong in a new section after the introduction that discusses the issues and intended changes in depth. However, they are not introduction.
> 
> 2. Section 1.3:
> 
> I still are uncertain if TURN channels needs the whole range 64 to 79. I think the text should be explicit about how many turn channels this support. So according to my math the proposed change is from 64-127 to 64-79, i.e. the available number of channels has been reduced from 16384 to 4096. That still a large number of channels.
> 
> What number of channels are currently used by implementations? I expect that to be single digit, or am I missing some use cases?
> 
> 3.  Section 1.4:
> 
> I still don't see how what is written in this section results in any improvement. You authors have assumptions of how this needs to be implemented that isn't written down. Looking on this problem of demultiplexing I would build a table driven solution based on the ranges, where the packet is sent to the relevant protocol based on the table-lookup. If that protocol don't use that value, that will be the end of the road for that packet as invalid, rather than giving it to any other protocol. I get the impression that you want one to send the packet for testing by the protocols one after each other according to the order the protocols are listed. I still don't see that implementations will do that.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 20 Oct 2015 17:05:32 +0000

Thanks, Paul.  We’ll try and formulate this section so that it is more of a simple table look-up without attempting to overlay any predetermined look-up algorithms or efficiencies.

Cheers,

Gonzalo

> On Oct 20, 2015, at 12:09 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> A natural implementation of this is via a switch statement. Each disjoint range of values is one case. (Detailed syntax varies by language.) A simple implementation of this may be implemented as a sequence of comparisons - a series of if/then/else such as you describe. a more time-optimal implementation uses a table lookup.
> 
> You shouldn't be mandating how this be implemented - only what the result is.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt