Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3)

["Black, David" <[e-mail]>]

Addressing solely this UDP item ...

>  What about UDP?  I doubt you'll find the notions in 5405bis to be quite
> right because they apply the rto-consider requirements to all
> UDP-based protocols.

The desired structure here (IMHO) is that the TCPM rto-consider draft
states the general principles, and the TSVWG rfc5405bis draft applies them
to UDP.  Then individual UDP-based protocol drafts are expected to follow
the guidance in rfc5405bis, or explain why there are good reasons for
doing otherwise.

> And, so, I think all the same arguments you're
> making now would have to be applied there, too, and so we'll have to
> go and write N more of these things for N UDP-based apps.  

Not exactly - any UDP-based protocol RFC-to-be is going to have to
reference rfc5405bis, as I'd expect the TSV ADs to Discuss drafts that
don't ;-).  The resulting RTO considerations will show up in each main
protocol draft, not a small separate stand-alone draft.

In practice, we'll probably see more cross-area interaction to head off
this class of issue before it hits the IESG.  FWIW, draft-ietf-forces-interfelfb
is a recently-worked example in the area of congestion considerations,
and I do want to thank the responsible RTG AD (Alia) for noticing that
the congestion concerns could use a bit more attention, and encouraging
the draft authors to address them in advance of the draft going to the IESG.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Mark Allman
> Sent: Monday, June 20, 2016 10:45 AM
> To: Scharf, Michael (Nokia - DE)
> Cc: [e-mail]; [e-mail]
> Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3)
> 
> 
> > If [rto-consider] is IETF consensus, IMHO a 6298bis document would
> > be a no-brainer in TCPM.
> 
> But, it isn't necessary.  RFC 6298 is a document about *one*
> algorithm.  We could invent parallel algorithms.  And, write an RFC
> that specifies each.  RFC 6298 just happens to be the only RTO we
> have taken the bother to develop and write up.  So, RFC 6298 (or a
> bis) doesn't have to convey all of our TCP RTO understanding.  It is
> just one algorithm for doing it.
> 
> So, yeah, we can write a preamble to RFC 6298 that says "this agrees
> with [rto-consider]", but that doesn't change the algorithm.  It
> isn't a technical change at all.  It is more words in service of
> what?  A tidy---by some definition---document progression is all I
> can come up with.  It doesn't advance things in any meaningful way.
> 
> > One added value of 6298bis is that it applies the
> > generic wording in [rto-consider] specifically to the TCP. I
> > believe that this is simpler to read for a TCP implementer than to
> > reverse-engineer protocol-agnostic wording in a draft that gets
> > longer and longer to be protocol-agnostic (and likely will have to
> > be further extended when it hits IETF last call)?
> 
> The whole thing hasn't really gotten much longer.  And, it is still
> quite short.  And, I don't think that someone steeped in TCP will
> have a difficult time reading the generic form of the requirements
> there now.  These are not particularly foreign concepts we're
> talking about.
> 
> > So is your concern that nobody would invest cycles to author a
> > 6298bis in TCPM? Or something equivalent e.g. for SCTP?
> 
> My concern is for doing work that just doesn't need to be done.  How
> many times do you want to re-state the same thing?  TCP, SCTP.  What
> about UDP?  I doubt you'll find the notions in 5405bis to be quite
> right because they apply the rto-consider requirements to all
> UDP-based protocols.  And, so, I think all the same arguments you're
> making now would have to be applied there, too, and so we'll have to
> go and write N more of these things for N UDP-based apps.  That's
> saying the same thing a lot.  And, God forbid if we ever had to
> change something...
> 
> The point is that except for document series tidiness I have seen no
> reason to make these requirements only apply to future specs---and
> not implementations---as you advocate.
> 
> allman
> 
>