Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice

[tom petch <[e-mail]>]

> ----- Original Message -----
> From: "Mark Allman" <[e-mail]>
> 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
>>
>>