Subject: [tsvwg] UDP vs. IP usage guidelines (draft-ietf-tsvwg-rfc5405bis)

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Mar 2015 14:49:01 -0500

Gorry,

As I said at the mike, most of the UDP usage guidelines document applies 
equally to applications and tunnels that use IP.
The only part that clearly doesn't apply is the port number aspect.

I don't want to create the impression that applications or tunneling 
approaches can dealing with this issues by running over IP instead of 
running over UDP.

I wonder whether it would make sense to add a section saying that the 
guidelines applies to using other datagram protocols (that do not have 
their own congestion control mechanism i.e. exclude DCCP).

Alternatively it might make sense to introduce a separate IP usage 
guidelines document in intarea which says in essence "everything but 
section 5.1 in draft-ietf-tsvwg-rfc5405bis applies to applications or 
tunnels that use IP". But that sounds a lot more heavy weight.

Regards,
    Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Mar 2015 09:44:46 +1300

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

On 27/03/2015 08:49, Erik Nordmark wrote:
> 
> Gorry,
> 
> As I said at the mike, most of the UDP usage guidelines document applies equally to applications and tunnels that use IP.
> I don't want to create the impression that applications or tunneling approaches can dealing with this issues by running over IP
> instead of running over UDP.
> 
> I wonder whether it would make sense to add a section saying that the guidelines applies to using other datagram protocols (that
> do not have their own congestion control mechanism i.e. exclude DCCP).
> 
> Alternatively it might make sense to introduce a separate IP usage guidelines document in intarea which says in essence
> "everything but section 5.1 in draft-ietf-tsvwg-rfc5405bis applies to applications or tunnels that use IP". But that sounds a
> lot more heavy weight.

Especially since it would contain a very interesting section on firewalls and NATs.

    Brian