wiki:tsvdir-common-issues

Transport Directorate Review Common Issues

The TSV directorate reviews selected documents within the transport area and selected documents from other areas. This page describes some common issues that might come up in TSV reviews.. We should publish guidelines that identify transport-related issues and point to the documents that contain further discussion.

We plan to have TSVDIR develop such guidelines, and to turn them into a checklist for TSVDIR reviews. The checklist and guidelines can be advertised to authors so their documents address the issues properly before we do TSVDIR reviews, and during TSVDIR reviews, we can check the checklist to make sure they considered the relevant issues.

TSVDIR guideline regarding use of _tcp and _udp in SRV

The first label of the pair is an underscore character followed by the Application Protocol Name, and the second label is either "_tcp" or "_udp".

For applications using transport protocols other than TCP, such as SCTP, DCCP, Adobe's RTMFP, etc., the second label of <service> portion of its DNS-SD name should be "_udp"."

This method is to discover the service, and we want to keep the barrier low for using new transports ... creating new DNS entries for each would create a problem in introducing new transports - they would rely on new DNS provision, and mDNS support.

DBH advice to TSVDIR reviewers: Please flag any document that deals with service assignment and discovery. There is debate in the community about which is the right way to do assignments for new services. Currently, only _tcp and _udp should be used, but that guideline could change, so please make the AD aware there is an assignment.

Use of UDP

See these guidelines: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ (an update to http://tools.ietf.org/html/rfc5405)

Limiting protocol applicability to Controlled Environments (see Section 3.6 of the rfc5405bis draft) allows relaxing of general Internet requirements (e.g., for congestion control) under suitable (e.g., operator) control, but the limited applicability should be clearly stated.

Does the protocol use zero UDP checksums with IPv6? If so, does the document explain how the protocol meets the requirements in http://tools.ietf.org/html/rfc6935 and http://tools.ietf.org/html/rfc6936 ? Explanation is necessary because these RFCs include protocol design requirements.

Timers

If a protocol contains timers, the reviewer should consider whether there is a default value given, or a formula/algorithm for managing the timer.

Is it static or does it adjust based on the sensed network conditions or protocol activity?

Is there potential for multiple nodes, connections, or other protocol instances have their timers synchronize and cause undesirable effects? E.g. should the timer be randomly dithered.

Retries

Does the protocol perform retransmissions? If so, how are these triggered, and is there potential for an inrush of them?

If there's a feedback mechanism, is its scalability well-understood and can it be impacted by path asymmetry?

PDU Sizes

Is there a potential issue with IP fragmentation that the protocol implies? Does it deal with this potential adequately?

Is PLPMTUD (see http://tools.ietf.org/html/rfc4821) included where applicable to avoid black-holing that arises when ICMPs are blocked? Does the document explain how the protocol uses PLPMTUD?

Middleboxes

Will the protocol be impacted by NAT? If it deals with NAT, does it utilize typical mechanisms (e.g. STUN, TURN, ICE), or invent new ones?

Use of Experimental Codepoints

In some cases, protocol values have been set aside for Experimental use. These should not be used by protocols proposed for the Standards Track or whose deployment is expected to be widescale and enabled by default. See also RFC6994 on a way to use these options for shared use; this is defined for TCP, but can be extended to support similar uses for other experimental codepoints if needed.

Hijacking Codepoints

Many values, like TCP option numbers, port numbers, etc. need to be coordinated with IANA and must not simply be picked by a vendor on their own. This has happened with TCP option numbers in the past, which greatly complicates deployment of new mechanisms since it can lead to collisions. See BCP165, composed of RFC6335 and RFC7605. In specific, example codepoints in documents need to avoid "expected" values until assigned by IANA, and should never indicate use of an experimental codepoint as the default. See IANA considerations below.

Port Number Use

See BCP165, composed of RFC6335 and RFC7605. In particular, it is useful to avoid multiple ports for a single service, avoid deploying new insecure services (i.e., all services really ought to have security or at least optional security when deployed), etc.

Modifications to IETF Transport Protocols Done Outside of WGs

Sometimes documents that extend or modify IETF transport protocols (e.g. TCP, SCTP, etc.) may be submitted for publication through the ISE or other streams. This needs to be identified and carefully considered if it is the case, especially for core protocols like TCP.

Transport protocol parameters

Services that use existing transports need to clearly indicate how they interact with existing transport parameters. For TCP, this includes options that are compatible, expected, or incompatible, settings that are compatible, expected, or incompatible, etc. For example, an interactive service with messages longer than 1 byte SHOULD disable Nagle (RFC896).

Tunneling protocols and Transport Related Issues

It is common that Tunneling protocols miss to specify important transport related behavior. The two most common issues are around ECN and MTU reduction. ECN handling between inner and outer protocols have some important rules, and have requirements on ingress and egress nodes, see RFC6040 (http://www.rfc-editor.org/info/rfc6040). The other aspect is the impact on MTU tunnels have. Thus topics as fragmentation, and possible re-assembly, as well handling of the IP headers DF bit.

IANA Considerations

New codepoints for existing transports (e.g., TCP options, port numbers, service names) should use nonsense placeholders until confirmed by IANA. I.e., "NEW-PORT-TBD" should be used rather than any numerical port number, including those from the Dynamic or Experimental ranges.

Last modified 4 months ago Last modified on Mar 22, 2018, 10:31:58 AM