Subject: Re: [tsvwg] OPS-DIR review of draft-ietf-tsvwg-rfc5405bis-133

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 17 Jun 2016 13:11:49 +0000

Hi,

thanks for the review! I'll incorporate respective changes into -14.

On 2016-06-12, at 0:00, Tim Chown <[email-masked]> wrote:
> It might be nice to include some level of discussion of new examples of UDP-based protocols devised since RFC 5405 (i.e. since 2008), such as QUIC, or applications such as mosh that enable ssh over UDP rather than the traditional TCP.  Do these follow the guidance here, for example?

This would add quite a bit of digging - there is no spec for mosh, and while there is one for QUIC now, I'd require more time than I currently have to analyze if and how it follows the different guidelines we describe here. (I will however argue that if the QUIC WG forms, the eventual QUIC RFC should do so :-)

> CGNs have appeared since RFC 5405; are there specific issues they pose for UDP-based applications which require state to remain?

Other than being generally worse than normal NATs due to even faster timeouts? Not that I'm aware of.

> p.16 final para of point 1 - is most UDP-based communication congestion controlled?

I'd argue that most sent at volume, yes. Maybe with the exception of multicast, but that is limited in reach.

> p.30 when you say “competes fairly within an order of magnitude” do you mean on a 10G link that UDP can take over 9G?

Yes, actually, although that's obviously the extreme, non-ideal case. We wanted to make it clear that there is significant leeway, because TCP isn't "fair" to TCP either.

> p.30 in the next paragraph, this suggestion would seem non-trivial to implement well/accurately, and then the “order of magnitude” is thrown in too…

Yes, there is a lot of wiggle room here (on purpose).

> p.30 section 4.2 - perhaps reword as it implies explicit PMTUD to each known destination (receiver)?

I'm not sure it implies PMTUD - you'd normally have the MTU information available through other means in a multicast scenario.

> p.32 worth adding an example of why this is so valuable, e.g. DNS cache poisoning?

Which paragraph?

> p.34 perhaps note that the IPv6 Flow Label is mutable on path (section 6 of RFC 6437)

Is this important here?

Lars