----- Original Message -----
From: "Mark Allman" <mallman@xxxxxxxx>
Sent: Friday, May 29, 2020 1:45 PM
Hi Tom!
I am going to re-arrange slightly and deal with the last one first.
So I am conscious that the I-D comes out of the TCPM WG but it
seems as if it tries to be all encompassing;
Yes; we have found the guidelines are broadly applicable.
and I struggle to think of an application of the I-D which is not
TCP until some standards body develops a new transport protocol;
SCTP, QUIC, DNS, ... all manner of UDP applications. Several
things:
- In fact, RFC8085 (on UDP usage) includes many of the same things
(cribbed from this I-D in some cases, actually!). So, I think
your framing this as applying TCP guidance too widely is
incorrect.
- The WG chairs were conscious of this and explicitly got input
from folks working in these other (non-TCP) areas, as well.
- The WGLC was run in both tcpm and tsvwg.
So I do think this is quite a bit more widely applicable than TCP.
It did start its life as a TCP document, but grew in breadth as
folks have said "hey, that applies [here]" (e.g., most recently when
Jana noted this was quite applicable within QUIC). It has been
developed and reviewed as pretty general for a while now. I don't
think we're somehow trying to sneak something through that is
broader than it either should be or has been reviewed to be.
Mark
This is good to hear but I wish that more detail of this was in the I-D.
I have followed a number of Transport AD review of xxxx-over-UDP and it
was always about the need for flow control but never with the sort of
techniques that TCP uses, usually just a requirement for a statement on
rate limiting by the sender so if there are xxxx-over-UDP which measure
RTO and lost packets and act accordingly, then that would be excellent
to hear about. I know of none (and yes I am familiar with RFC8085) so
including non-TCP examples would counter the impression I have got that
this is TCP! SCTP I have always seen as son-of-TCP and so not much
different in this context. QUIC I have yet to encounter. As it stands,
the example of DNS caching server stands out to me as an example of
broader application, of the I-D in general; I would value more such
concrete examples. And below ...
I'll say something quick about the rest of the things, but basically
I am happy to add bits of clarification and fix sloppy writing.
When I got to "Within the standards process"
Will add "IETF".
I see an underlying assumption that the network is unreliable and
that the problem is packets discarded as a result of congestion.
A common assumption but untrue in some cases.
If your network is reliable then I presume you won't be reading
documents about loss detection. But, I dunno.
No, I am being unclear. It is the 'packets are lost due to congestion
and that is THE problem' that I see as the unstated assumption for this
and many IETF documents. Is it correct? Often, perhaps, but I struggle
to recall anyone testing the hypothesis and there is growing use of IETF
protocols over different kinds of networks where the problem is e.g.
interference and packet corruption so the recommended techniques will
give the user a worse experience - the corrupt packet needs
re-transmitting as soon as the interference is over and backing off the
flow rate is bad news for the user. And below...
We can add a sentence to the intro to explicitly say we are
discussing unreliable networks if that helps.
Likewise, I see an assumption that the recipient will always
generate an acknowledgement when asked. Again, untrue for some
protocols so again an assumption I would like to see stated.
I don't think we *assume* this is *always* the case. This is from
the document:
Various mechanisms are used to detect losses in a packet stream.
Often we use continuous or periodic acknowledgments from the
recipient to inform the sender's notion of which pieces of data
are
missing.
Without details, there is an acknowledgment there that there are
different ways to detect loss other than continuous ACKs. And, we
state "often we use" ACKs, which I think runs counter to your notion
that we "assume" "always". So, I am not sure what you want here.
Safety is mentioned many times; what is the danger? I do not know
and
would like to be told (congestive collapse?).
Safety in a congestion, not security, sense. I can add a quick
clarification on this.
Yes please, this is an example of what I generically refer to as a
lack of context, that for me safety is usually something quite
different in an I-D. And below ..
"protocols ultimately can only count on the passage of time
without delivery confirmation " true for some networks, not true
for others.
I struggle to think of a case where it doesn't apply. There are for
sure cases where we code the stream so that we get probabilistically
damn close to ensuring delivery without a continuous stream of ACKs
for specific packets. But, without some feedback ("delivery
confirmation") to the sender how could we ever be sure the data
arrived?
I do see a steady if small increase in IETF protocols to detect
and react to problems rather than waiting for someone else - like
TCP - to notice and do something so again I am seeing an
assumption.
I can't follow this. I don't mean to disagree with your
characterization of IETF protocols, but I don't understand how
you're applying that statement to the document.
It comes back to the assumption of a unreliable network, unreliable for
any reason, not just congestion. An alternative approach is to make the
network reliable and this I see as a strong interest of WG such as TEAS,
CCAMP, MPLS and such like. A statement up front about the assumption of
unreliability would address this.
Tom Petch
allman
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
