Re: [TLS] Transport Issues in DTLS 1.3

[Gorry Fairhurst <[e-mail]>]

Thanks Mark, my comments were also writen in haste, and I think relates 
to only some specific sections of the draft. It would be good to know 
what next steps are planned.

Gorry

On 25/03/2021 17:29, Mark Allman wrote:
> Folks-
>
> I am appending what I sent Martin & Gorry this morning.  I looked
> quite quickly as Martin was looking for quick input.  I am happy to
> iterate if things aren't all that understandable.
>
> allman
>
>
> [Quick hit.]
>
> I agree with Martin's DISCUSS and Gorry's notes.  A couple more
> things here ...
>
>> This spec looks a mess!
> A generous reading is that this is most of the problem.  I think
> maybe there is some intent in here that isn't stated very well.  It
> needs to be explicit and not as sloppy.
>
> A few specific things (in addition to what Gorry said, which I
> absolutely agree with):
>
>    - "Though timer values are the choice of the implementation,
>      mishandling of the timer can lead to serious congestion
>      problems"
>
>      + Gorry flagged this and I am flagging it again.  If this is
>        something that can lead to serious problems, let's not just
>        leave it to "choice of the implementation".  Especially if we
>        have some idea how to make it less problematic.
>
>    - "Implementations SHOULD use an initial timer value of 100 msec
>      (the minimum defined in RFC 6298 [RFC6298])"
>
>      + I wrote RFC 6298 and I have no idea where this is coming from!
>
>      + Even if this value of 100msec is OK for DTLS it shouldn't lean
>        on RFC 6298 because RFC 6298 doesn't say that is OK.  I.e.,
>        the parenthetical is objectively wrong.
>
>      + RFC 6298 says the INITIAL RTO should be 1sec (point (2.1) in
>        section 2).  RFC 8961 affirms this and also says the INITIAL
>        RTO should be 1sec (requirement (1) in section 4).
>
>    - "Note that a 100 msec timer is recommended rather than the
>      3-second RFC 6298 default in order to improve latency for
>      time-sensitive applications."
>
>      + Again, this mis-states RFC 6298, which says the initial RTO is
>        1sec (not 3sec).  (Previous to RFC 6298 the initial RTO was
>        3sec, which is probably where the notion comes from.  Most of
>        the purpose of RFC 6298 was to drop the initial RTO to 1sec.)
>
>      + This is a statement of desire, not any sort of principled
>        justification for using 100msec.  At the least this should be
>        much better argued.
>
>      + To me 100msec feels much too close to the RTT of some network
>        paths to be appropriate here.  To be clear, deviations from
>        RFC 8961 that gather consensus are fine, but you should say
>        why that deviation is OK.  And, I'd think the further you
>        deviate the more you need to say (for me).  I.e., dropping
>        from 1sec to 900msec may not be that big of an issue.  But,
>        dropping to 1/10-th of the guideline and to something pretty
>        close to not rare RTTs should require some care and some
>        discussion, IMO.
>
>      + And, I am not trying to be a picky protocol lawyer and say
>        this document "didn't check the RFC 8085 / RFC 8961 box".
>        Rather, RFC 8085 & 8961 say things for a reason and I don't
>        think we should implicitly ignore them because they come from
>        experience on how to do these sorts of things.
>
>    - "The retransmit timer expires: the implementation transitions to
>      the SENDING state, where it retransmits the flight, resets the
>      retransmit timer, and returns to the WAITING state."
>
>      + Maybe this is spec sloppiness, but boy does it sound like the
>        recipe TCP used before VJCC to collapse the network.  I.e.,
>        expire and retransmit the window.  Rinse and repeat.  It may
>        be the intention is for backoff to be involved.  But, that
>        isn't what it says.
>
>    - “When they have received part of a flight and do not immediately
>      receive the rest of the flight (which may be in the same UDP
>      datagram). A reasonable approach here is to set a timer for 1/4 the
>      current retransmit timer value when the first record in the flight
>      is received and then send an ACK when that timer expires.”
>
>      + Where does 1/4 come from?  Why is it "reasonable"?  This just
>        feels like a complete WAG that was pulled out of the air.
>
> And, +1 on all the flight size stuff Martin mentioned.
>
> allman