Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-ice-tcp-09.txt

From: [email-masked]
Date: Thu, 2 Sep 2010 04:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : TCP Candidates with Interactive Connectivity Establishment (ICE)
	Author(s)       : J. Rosenberg, et al.
	Filename        : draft-ietf-mmusic-ice-tcp-09.txt
	Pages           : 25
	Date            : 2010-09-02

Interactive Connectivity Establishment (ICE) defines a mechanism for
NAT traversal for multimedia communication protocols based on the
offer/answer model of session negotiation.  ICE works by providing a
set of candidate transport addresses for each media stream, which are
then validated with peer-to-peer connectivity checks based on Session
Traversal Utilities for NAT (STUN).  ICE provides a general framework
for describing candidates, but only defines UDP-based transport
protocols.  This specification extends ICE to TCP-based media,
including the ability to offer a mix of TCP and UDP-based candidates
for a single stream.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-09.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ari Keranen <[email-masked]>
Date: Thu, 02 Sep 2010 14:02:41 +0300

Hi all,

This updated version of the ICE TCP draft contains the changes discussed 
in the previous WG meeting:

* new authors
* the ICE TCP framework draft was merged into this draft
   - instead of just STUN & TURN, various kind of NAT traversal 
mechanisms are listed and their implementation encouraged
   - prioritization recommendations for the new methods
   - removed and/or generalized STUN & TURN specific text
* added Appendix A where limitations of TCP based NAT traversal is 
discussed

Comments and reviews are very welcome!

Cheers,
Ari

On 09/02/2010 02:00 PM, [email-masked] wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Simon Perreault <[email-masked]>
Date: Thu, 02 Sep 2010 08:26:09 -0400

> * added Appendix A where limitations of TCP based NAT traversal is

This is great news! Thanks!

I'm very happy with all the changes.

One thing I think is missing is a comprehensive example. Tons of
different candidates would be gathered by as many means as we can think
of, and then we would show the resulting monstrous SDP. That would be
awesome.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Frank Shearar <[email-masked]>
Date: Thu, 02 Sep 2010 14:50:03 +0200

> 	Filename        : draft-ietf-mmusic-ice-tcp-09.txt

Grammar nit:

Section 1, 2nd paragraph:

   In addition, also RTP can run over TCP [RFC4571].

should be

   In addition, RTP can also run over TCP [RFC4571].

I'm happy to see progress being made on this important topic!

frank

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Sep 2010 16:32:30 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Thursday, September 02, 2010 5:26 AM
> To: [email-masked]
> Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-ice-tcp-09.txt
> 

That would give the implication it is ICE's fault that SDP is big,
or give the implication that a host with multiple interfaces is 
going to necessarily have STUN and TURN servers on all of those
interfaces.

Magnus built a big SDP example in 2006, 
  http://www.ietf.org/mail-archive/web/mmusic/current/msg04204.html
His example was 301 lines (10,745 bytes).  Removing all of the ICE
lines (a=candidate, a=ice) drops it down to 244 lines (7719 bytes).

In any event, if we're going to do a big example, how about
a real example in draft-ietf-sipping-nat-scenarios, if it 
doesn't have it already?

-d

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Sep 2010 07:31:50 +0200

Then, add some capNeg stuff to it, and you'll need a separate draft just for a single SDP example...

Regards,

Christer 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan Wing
> Sent: 3. syyskuuta 2010 2:33
> To: 'Simon Perreault'; [email-masked]
> > different candidates would be gathered by as many means as we can 
> > think of, and then we would show the resulting monstrous SDP. That 
> > would be awesome.
> 
> That would give the implication it is ICE's fault that SDP is 
> big, or give the implication that a host with multiple 
> interfaces is going to necessarily have STUN and TURN servers 
> on all of those interfaces.
> 
> His example was 301 lines (10,745 bytes).  Removing all of 
> the ICE lines (a=candidate, a=ice) drops it down to 244 lines 
> (7719 bytes).
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Sep 2010 22:42:49 -0700

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, September 02, 2010 10:32 PM
> To: Dan Wing; 'Simon Perreault'; [email-masked]
> Subject: RE: [MMUSIC] I-D Action:draft-ietf-mmusic-ice-tcp-09.txt
> 
> 

:-)

-d

> > =

---

From: Simon Perreault <[email-masked]>
Date: Fri, 03 Sep 2010 08:33:36 -0400

> That would give the implication it is ICE's fault that SDP is big,

For me, this is a minor concern.

> going to necessarily have STUN and TURN servers on all of those

Nah, just preface the example with some text explaining that this is a
full-blown example, real-life will be simpler, yadda yadda yadda...

> a real example in draft-ietf-sipping-nat-scenarios, if it 

I don't care where it is, but we need one. When you're implementing
something, you end up looking longer at examples than at the actual
spec. It really is extremely useful.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Sep 2010 08:48:39 -0700

> Sent: Friday, September 03, 2010 5:34 AM
> To: Dan Wing
> Cc: [email-masked]

Agreed.

-d

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 03 Sep 2010 10:11:07 -0700

> spec. It really is extremely useful.

And, in my opinion, terribly wrong.  I personally would ban all examples from
RFC, because at best they are exposing only a subset of what the RFC describe
and at worst there is bugs in it, bugs[1] that you will then find in
implementations.

[1] See errata #562, 534, 507, 588, 589, 503, 749, 481, 469, 615, 619, 446, 447,
872, 435, 432, 645, 649, 650, 651, 391, 1839, 362, 359, 1080, 349, 299, 246,
1004, 704, 873, 1525, 631, 1681, 1352, 1716, 852, 781, 828, 727, 948, 1476,
1785, 1376, 2270, 2271, 1068, 1803, 1685, 1808, 1993, 1916, 2039, 1083, 1899,
1813, 452, 440, 442, 443, 444, 411, 1432, 2258, 1469, 2261, 1500, 1273, 1009,
1605, 2030...

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Ari Keranen <[email-masked]>
Date: Fri, 03 Sep 2010 23:28:50 +0300

> and at worst there is bugs in it, bugs[1] that you will then find in

I agree with Simon that an example would be really useful, but I think 
also Marc is right that having it wrong is likely worse than not having 
it at all.

Since we have a draft (the nat-scenarions one) that is already 
documenting this kind of things, I'd say that would be a better place 
for the example and we can add an informative reference so that 
implementors know where to look at.

Also, the examples in the nat-scenarios draft should probably be run 
through multiple real implementations and still would need disclaimers 
saying "there are probably errors in the examples, so take a look at the 
errata, etc.", but that's a whole other story..

Cheers,
Ari

---

From: Ari Keranen <[email-masked]>
Date: Fri, 03 Sep 2010 23:29:17 +0300

> In addition, RTP can also run over TCP [RFC4571].

OK, we'll fix that. Thanks!

> I'm happy to see progress being made on this important topic!

Thanks, we're also hoping to get this ready for WGLC as soon as possible 
and feedback from all you guys definitely helps with this.

Cheers,
Ari

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 03 Sep 2010 15:39:51 -0700

> errata, etc.", but that's a whole other story..

The way I managed the examples in my recently published RFC[1] is twofold:

1. I refused to add examples to explain something until the normative text
itself was clear enough to in fact make the examples redundant.  Examples are
fine for people that are just interested in vaguely understanding what it is
about but implementers should not look at examples, or at any section titled
"Introduction", "Overview" or "Informative References".  I wish I could somehow
filter this sections automatically when my developers upload RFC from the Internet.

2. I generated automatically the examples in the spec.  I first wrote a
reference implementation[2] of the RFC.  Then I added unit tests to verify that
my reference implementation was correct.  Then finally I wrote the code listed
in [3] that automatically generates the RFC2629 fragments listed in [4],
fragments that are automatically merged in the draft using Xinclude.  Because
the examples were generated each time I built the text version of the draft, I
was sure that the examples were correct - or at least as correct as my reference
implementation.

[1] https://datatracker.ietf.org/doc/rfc5928/
[2] http://debian.implementers.org/stable/source/turnuri.tar.gz
[3]
example("turn:example.net", Arrays.asList(TLS, TCP, UDP), new MockDirContext(
  domain("example.net.",
    record(NAPTR,
      "100 10 \"\" RELAY:turn.udp \"\" datagram.example.net.",
      "200 10 \"\" RELAY:turn.tcp:turn.tls \"\" stream.example.net.")),
  domain("datagram.example.net.",
    record(NAPTR, "100 10 S RELAY:turn.udp \"\" _turn._udp.example.net.")),
  domain("stream.example.net.",
    record(NAPTR,
      "100 10 S RELAY:turn.tcp \"\" _turn._tcp.example.net.",
      "200 10 A RELAY:turn.tls \"\" a.example.net.")),
  domain("_turn._udp.example.net.",
    record(SRV, "0 0 3478 a.example.net.")),
  domain("_turn._tcp.example.net.",
    record(SRV, "0 0 5000 a.example.net.")),
  domain("a.example.net.",
    record(A, "192.0.2.1"))), 1, true);
example("turn:example.com", Arrays.asList(TLS, TCP, UDP), new MockDirContext(
  domain("example.com.",
    record(NAPTR,
      "100 10 \"\" RELAY:turn.udp:turn.tcp:turn.tls \"\" example.net."))), 2,
false);
example("turn:example.net", Arrays.asList(TLS, TCP, UDP), new MockDirContext(
  domain("_turn._udp.example.com.",
    record(SRV, "0 0 3478 a.example.net.")),
  domain("_turn._tcp.example.com.",
    record(SRV, "0 0 5000 a.example.net.")),
  domain("_turns._tcp.example.com.",
    record(SRV, "0 0 5349 a.example.net."))), 3, false);

[4]
<figure anchor="dns-rr1"><artwork><![CDATA[example.net.
IN NAPTR 100 10 "" RELAY:turn.udp "" datagram.example.net.
IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net.

datagram.example.net.
IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net.

stream.example.net.
IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net.
IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net.

_turn._udp.example.net.
IN SRV   0 0 3478 a.example.net.

_turn._tcp.example.net.
IN SRV   0 0 5000 a.example.net.

a.example.net.
IN A     192.0.2.1

]]></artwork></figure>

<figure anchor="dns-rr2"><artwork><![CDATA[example.com.
IN NAPTR 100 10 "" RELAY:turn.udp:turn.tcp:turn.tls "" example.net.
]]></artwork></figure>

<figure anchor="dns-rr3"><artwork><![CDATA[_turn._udp.example.com.
IN SRV   0 0 3478 a.example.net.

_turn._tcp.example.com.
IN SRV   0 0 5000 a.example.net.

_turns._tcp.example.com.
IN SRV   0 0 5349 a.example.net.

]]></artwork></figure>

<texttable anchor="result1"><ttcol>Order</ttcol><ttcol>Protocol</ttcol><ttcol>IP
address</ttcol><ttcol>Port</ttcol><c>1</c><c>UDP</c><c>192.0.2.1</c><c>3478</c><c>2</c><c>TLS</c><c>192.0.2.1</c><c>5349</c><c>3</c><c>TCP</c><c>192.0.2.1</c><c>5000</c></texttable>

- -- 
Marc Petit-Huguenin

---

From: Ari Keranen <[email-masked]>
Date: Mon, 06 Sep 2010 23:45:12 +0300

> filter this sections automatically when my developers upload RFC from the Internet.

I agree that implementers should not rely on examples, but they can make 
understanding the specs much easier too and can be therefore really 
useful. That said, given how easily errors creep into examples, I'm 
usually a bit reluctant on having really specific examples in something 
as immutable as an RFC.
> was sure that the examples were correct - or at least as correct as my reference

Nice tool chain you got! Something like that would be good also for the 
examples of ICE TCP if we end up having such in the nat-scenarios draft.

Cheers,
Ari

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 06 Sep 2010 14:09:31 -0700

> usually a bit reluctant on having really specific examples in something

I think that a good first step would be to move all the examples in future RFCs
in a separate section, and explicitly declare this section as non-normative.

> examples of ICE TCP if we end up having such in the nat-scenarios draft.

I will be happy to help, especially because there is an ICE TCP implementation
in my future.

- -- 
Marc Petit-Huguenin

---

From: Ari Keranen <[email-masked]>
Date: Wed, 08 Sep 2010 21:44:58 +0300

> in a separate section, and explicitly declare this section as non-normative.

That would make sense.

> I will be happy to help, especially because there is an ICE TCP implementation

That would be excellent, thanks!

Cheers,
Ari

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 17 Sep 2010 15:30:20 +0300

Hi Ari,

> examples of ICE TCP if we end up having such in the nat-scenarios draft.

Robert is already performing his AD review on the nat-scenarios draft.
So, I am not sure whether he would like to add yet another example to
the draft at this point... in any case, he has currently the token.

Cheers,

Gonzalo

---

From: Ari Keranen <[email-masked]>
Date: Fri, 17 Sep 2010 16:40:28 +0300

Hi Gonzalo,

> the draft at this point... in any case, he has currently the token.

OK, in that case it's probably not worth the hassle to add more examples 
there. Thanks for the info!

Cheers,
Ari