[tram] Mirja Kühlewind's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)

Mirja Kühlewind <ietf@kuehlewind.net> Fri, 21 September 2018 08:48 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tram-stun-pmtud@ietf.org, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, Tolga Asveren <tasveren@rbbn.com>, tram-chairs@ietf.org, tasveren@rbbn.com, tram@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153751972590.7455.6938488192174769057.idtracker@ietfa.amsl.com>
Date: Fri, 21 Sep 2018 01:48:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/L927uXQTRSBK7lHL_rDgi-3LFII>
Subject: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tram-stun-pmtud-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Based on the transport review provided by Gorry (Thanks!), please clarify the
applicability (as you claim the "usage is not limited to STUN-based protocols")
and the relation to draft-ietf-tsvwg-datagram-plpmtud.

Further, more discussion on impact of reordering, loss, and congestion control
is probably needed (also see Gorry's review).

Regarding sec 4.2.5, as mentioned by Gorry, it is probably not possible to use
the UPD checksum because it might change on the path.

And finally, I have two questions on sec 4.2.6.:

1) I don't quite understand how the identifier "shim" is used. I guess this
would be needed on all UDP packet and it should be negotiated/indicated between
the client and the server. How is that done?

2) Also why does the sequence number needs to be "monotonically incremented by
one for each packet sent". I think all you need is a unique number. So you
actually don't need a sequence number but that an easy implementation to get a
unique number. I would like to see this clarifed because adding a sequence
number might not always be the best choice.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Sec 4.2.2 says: "If the Probe Indication identifier cannot be found in the Report
   Response, this is interpreted as a Probe Failure, as defined in
   [RFC4821] Section 7.5.  If the Probe Indication identifier cannot be
   found in the Report Response but identifiers for other packets sent
   before or after the Probe Indication can all be found, this is
   interpreted as a Probe Failure as defined in [RFC4821] Section 7.5"
However, RFC4821 seems to only see the second case as an failure.

[tram] Mirja Kühlewind's Discuss on draft-ietf-tr… Mirja Kühlewind