Re: [rtcweb] Extended Last Call: <draft-ietf-rtcweb-transports-14.txt> (Transports for WebRTC) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I have reviewed this document in IETF last call, sorry I missed the last WG last call, thus in this stage instead. I do support the publication of this document. However, I think the below comments do need to be considered before publication approval.

1. Section 3.3:


   When a client gathers all IPv6 addresses on a host, and both
   temporary addresses and permanent addresses of the same scope are
   present, the client SHOULD discard the permanent addresses before
   exposing addresses to the application or using them in ICE.  This is
   consistent with the default policy described in [RFC6724].

   If some of the temporary IPv6 addresses, but not all, are marked
   deprecated, the client SHOULD discard the deprecated addresses.

I haven't noticed this before, but if you have both permanent and temporary addresses, can all the temporary be marked deprecated? If that can occur, does this specification need to say something in this case which should be used, a deprecated temporary or a permanent one?

2. Section 3.4:

   If TCP connections are used, RTP framing according to [RFC4571] MUST
   be used, both for the RTP packets and for the DTLS packets used to
   carry data channels.

I think the last part of this sentence, unintentionally excludes the DTLS handshake packets. The ICE TCP spec also specifies that the STUN connectivity checks are using RFC4571 framing. Thus, I think some reformulation of this sentence is in order.

3. Section 3.5:

   WebRTC implementations MUST support multiplexing of DTLS and RTP over
   the same port pair, as described in the DTLS-SRTP specification
   [RFC5764], section 5.1.2.  All application layer protocol payloads
   over this DTLS connection are SCTP packets.

This text should reference also the update to RFC5764:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/

That document is publication requested so even as normative reference it will hopefully have minimal impact on the publication progress of this document.

4. Section 4.2:

   The implementation MAY turn off use of DSCP markings if it detects
   symptoms of unexpected behaviour like priority inversion or blocking
   of packets with certain DSCP markings.  The detection of these
   conditions is implementation dependent.

As raised on the TSVWG and RTCWEB mailing list recently in regards to draft-ietf-tsvwg-rtcweb-qos there have been a recent study (https://irtf.org/anrw/2016/anrw16-final17.pdf) showing that non zero DSCP values resulted in consistent failures in 10-13% of the tested paths. So I think it worth considering if this text needs to be sharpen, and possibly actually point to a solution that needs to be specified?

5. Section 8.1:

   [I-D.martinsen-mmusic-ice-dualstack-fairness]
              Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6
              Dual Stack Fairness", draft-martinsen-mmusic-ice-
              dualstack-fairness-02 (work in progress), February 2015.

Can be updated as this is now an WG item in ICE.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
----------------------------------------------------------------------




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]