draft-ietf-tram-stun-path-data-00.txt   draft-ietf-tram-stun-path-data-01.txt 
TRAM T. Reddy TRAM T. Reddy
Internet-Draft D. Wing Internet-Draft D. Wing
Intended status: Standards Track P. Martinsen Intended status: Standards Track P. Martinsen
Expires: October 9, 2015 Cisco Expires: October 9, 2015 Cisco
V. Singh V. Singh
callstats.io callstats.io
April 7, 2015 April 7, 2015
Discovery of path characteristics using STUN Discovery of path characteristics using STUN
draft-ietf-tram-stun-path-data-00 draft-ietf-tram-stun-path-data-01
Abstract Abstract
A host with multiple interfaces needs to choose the best interface A host with multiple interfaces needs to choose the best interface
for communication. Oftentimes, this decision is based on a static for communication. Oftentimes, this decision is based on a static
configuration and does not consider the path characteristics, which configuration and does not consider the path characteristics, which
may affect the user experience. may affect the user experience.
This document describes a mechanism for an endpoint to discover the This document describes a mechanism for an endpoint to discover the
path characteristics using Session Traversal Utilities for NAT (STUN) path characteristics using Session Traversal Utilities for NAT (STUN)
skipping to change at page 2, line 30 skipping to change at page 2, line 30
3.1. The PATH-CHARACTERISTIC attribute in request . . . . . . 4 3.1. The PATH-CHARACTERISTIC attribute in request . . . . . . 4
3.2. The PATH-CHARACTERISTIC attribute in response . . . . . . 5 3.2. The PATH-CHARACTERISTIC attribute in response . . . . . . 5
3.3. Example Operation . . . . . . . . . . . . . . . . . . . . 6 3.3. Example Operation . . . . . . . . . . . . . . . . . . . . 6
4. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The ICE [RFC5245] mechanism uses a prioritization formula to order The ICE [RFC5245] mechanism uses a prioritization formula to order
the candidate pairs and perform connectivity checks, in which the the candidate pairs and perform connectivity checks, in which the
most preferred address pairs are tested first and when a sufficiently most preferred address pairs are tested first and when a sufficiently
good pair is discovered, that pair is used for communications and good pair is discovered, that pair is used for communications and
further connectivity tests are stopped. This approach works well for further connectivity tests are stopped. This approach works well for
an endpoint with a single interface, but is too simplistic for an endpoint with a single interface, but is too simplistic for
endpoints with multiple interfaces, wherein a candidate pair with a endpoints with multiple interfaces, wherein a candidate pair with a
skipping to change at page 2, line 52 skipping to change at page 2, line 52
round-trip time, loss, etc.). The ICE connectivity checks can assist round-trip time, loss, etc.). The ICE connectivity checks can assist
in measuring the path characteristics, but as currently defined, the in measuring the path characteristics, but as currently defined, the
STUN responses to re-transmitted requests are indistinguishable from STUN responses to re-transmitted requests are indistinguishable from
each other. each other.
This draft extends STUN [RFC5389] to distinguish STUN responses to This draft extends STUN [RFC5389] to distinguish STUN responses to
re-transmitted requests and this assists the client in determining re-transmitted requests and this assists the client in determining
the path characteristics like round-trip time (RTT) and packet loss the path characteristics like round-trip time (RTT) and packet loss
in each direction between endpoints. These metrics can then be used in each direction between endpoints. These metrics can then be used
by the controlling agent to influence the ICE candidate pair by the controlling agent to influence the ICE candidate pair
priorities. selection.
The PATH-CHARACTERISTICS attribute introduced in this specification The PATH-CHARACTERISTICS attribute introduced in this document can be
can be used in ICE connectivity checks (STUN Binding request and used in ICE connectivity checks (STUN Binding request and response).
response). When multiple TURN servers are discovered then this new When multiple TURN servers are discovered then this new attribute can
attribute can also be used with Allocate request to determine the also be used with Allocate request to determine the priority amongst
priority amongst the relayed candidates. the relayed candidates.
This specification can be used with the regular nomination procedure The technique described in this document can be used with the regular
defined in ICE, wherein ICE connectivity checks need to be performed nomination procedure defined in ICE [RFC5245], wherein ICE
on all or subset of the chosen candidate pairs. Finalizing an connectivity checks need to be performed on all or subset of the
approporiate candidate pair based on the path characteristics depends chosen candidate pairs. Finalizing an appropriate candidate pair
on the number of candidate pairs, time interval for pacing ICE based on the path characteristics depends on the number of candidate
connectivity checks and the corresponding RTO values. By picking pairs, time interval for pacing ICE connectivity checks and the
appropriate values the endpoints will not observe any noticeable corresponding RTO values. By picking appropriate values, the
impact to the media setup time. endpoints will not observe any noticeable impact in the media setup
time.
TODO: Add details of ICE continous nomination procedure discussed in The technique described in this document can also be used with the
mmusic WG which allows picking better candidate pairs as and when ICE continuous nomination procedure explained in
they appear. http://juberti.github.io/draughts/nombis/draft-uberti- [I-D.uberti-mmusic-nombis] which allows the application to pick
mmusic-nombis.html explains simplifying and improving the procedures better candidate pairs as and when they appear. Hence, ICE endpoints
for candidate nomination in ICE to make dynamic decisions. will be capable of switching the media stream to a candidate pair
that becomes available later and offers better path characteristics.
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This note uses terminology defined in ICE [RFC5245] and STUN This note uses terminology defined in ICE [RFC5245] and STUN
[RFC5389]. [RFC5389].
skipping to change at page 4, line 7 skipping to change at page 4, line 8
Further, several STUN requests may be sent before the connectivity Further, several STUN requests may be sent before the connectivity
between candidate pairs is ascertained (see Section 16 of [RFC5245]). between candidate pairs is ascertained (see Section 16 of [RFC5245]).
To resolve the issue of identical request and response packets in a To resolve the issue of identical request and response packets in a
STUN transaction, this document changes that retransmission behavior STUN transaction, this document changes that retransmission behavior
for idempotent packets. In addition to determining RTT, it is also for idempotent packets. In addition to determining RTT, it is also
desirable to detect which path direction caused packet loss, desirable to detect which path direction caused packet loss,
described as "bi-directional path characteristics," below. This is described as "bi-directional path characteristics," below. This is
achieved by defining a new STUN attribute and requires compliant STUN achieved by defining a new STUN attribute and requires compliant STUN
(TURN, ICE) endpoints to count request packets. (TURN, ICE) endpoints to count request packets.
This specification defines a new comprehension-optional STUN This document defines a new comprehension-optional STUN attribute
attribute PATH-CHARACTERISTIC. PATH-CHARACTERISTIC will have a STUN PATH-CHARACTERISTIC. PATH-CHARACTERISTIC will have a STUN Type TBD-
Type TBD-CA. This type is in the comprehension-optional range, which CA. This type is in the comprehension-optional range, which means
means that STUN agents can safely ignore the attribute if they do not that STUN agents can safely ignore the attribute if they do not
understand it. understand it.
If a client wishes to determine the path characteristics, it inserts If a client wishes to determine the path characteristics, it inserts
the PATH-CHARACTERISTIC attribute in a STUN request. In the PATH- the PATH-CHARACTERISTIC attribute in a STUN request. In the PATH-
CHARACTERISTIC attribute client sends the number of times the STUN CHARACTERISTIC attribute client sends the number of times the STUN
request is retransmitted with the same Transaction ID. The server request is retransmitted with the same Transaction ID. The server
would echo back the retransmission count in the response so that would echo back the retransmission count in the response so that
client can distinguish STUN responses from the re-transmitted client can distinguish STUN responses from the re-transmitted
requests. Hence, the endpoint can use the STUN requests and requests. Hence, the endpoint can use the STUN requests and
responses to determine the round-trip time (RTT). The server may responses to determine the round-trip time (RTT). The server may
also convey the number of times it received the request with the same also convey the number of responses it has sent for the STUN request
Transaction ID and the number of responses it has sent for the STUN to the client. Further, this information enables the client to
request to the client. Further, this information enables the client determine packet loss in each direction.
to determine packet loss in each direction.
3.1. The PATH-CHARACTERISTIC attribute in request 3.1. The PATH-CHARACTERISTIC attribute in request
The PATH-CHARACTERISTIC attribute in a STUN request takes a 1-byte The PATH-CHARACTERISTIC attribute in a STUN request takes a 4-byte
Value, which means that the Length is 1 and 3 bytes of padding are Value. When sending a STUN request, the PATH-CHARACTERISTIC
required after the value (Section 15 of [RFC5389]). When sending a attribute allows a client to indicate to the server that it wants to
STUN request, the PATH-CHARACTERISTIC attribute allows a client to determine path characteristics. If the client receives a STUN
indicate to the server that it wants to determine path response with error code 420 (Unknown Attribute) and PATH-
characteristics. If the client receives a STUN response with error CHARACTERISTIC is listed in the UNKNOWN-ATTRIBUTE attribute of the
code 420 (Unknown Attribute) and PATH-CHARACTERISTIC is listed in the message, the client SHOULD retransmit the original request without
UNKNOWN-ATTRIBUTE attribute of the message, the client SHOULD the PATH-CHARACTERISTIC attribute. However this case is not expected
retransmit the original request without the PATH-CHARACTERISTIC to occur, due to the use of the comprehension-optional attribute
attribute. However this case is not expected to occur, due to the type.
use of the comprehension-optional attribute type.
This specification updates one the STUN message structuring rules This document updates one the STUN message structuring rules
explained in Section 6 of [RFC5389] that resends of the same request explained in Section 6 of [RFC5389] that resends of the same request
reuse the same transaction ID and are bit-wise identical to the reuse the same transaction ID and are bit-wise identical to the
previous request. For idempotent packets the ReTransCnt in the PATH- previous request. For idempotent packets the ReTransCnt in the PATH-
CHARACTERISTIC attribute will be incremented by 1 for every re- CHARACTERISTIC attribute will be incremented by 1 for every re-
transmission and the re-transmitted STUN request MUST be bit-wise transmission and the re-transmitted STUN request MUST be bit-wise
identical to the previous request except for the ReTransCnt value. identical to the previous request except for the ReTransCnt value.
The format of the value in PATH-CHARACTERISTIC attribute in the The format of the value in PATH-CHARACTERISTIC attribute in the
request is: request is:
0 0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ReTransCnt | | Reserved, should be 0 | ReTransCnt | RespTransCnt |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH-CHARACTERISTIC attribute in request Figure 1: PATH-CHARACTERISTIC attribute in request
The field is described below: The field is described below:
ReTransCnt: Number of times request is re-transmitted with the same ReTransCnt: Number of times request is re-transmitted with the same
transaction ID to the server. transaction ID to the server.
RespTransCnt: RespTransCnt MUST be set to zero in request and
ignored by the receiver.
3.2. The PATH-CHARACTERISTIC attribute in response 3.2. The PATH-CHARACTERISTIC attribute in response
When a server receives a STUN request that includes a PATH- When a server receives a STUN request that includes a PATH-
CHARACTERISTIC attribute, it processes the request as per the STUN CHARACTERISTIC attribute, it processes the request as per the STUN
specification [RFC5389] plus the specific rules mentioned here. The protocol [RFC5389] plus the specific rules mentioned here. The
server checks the following: server checks the following:
o If the PATH-CHARACTERISTIC attribute is not recognized, ignore the o If the PATH-CHARACTERISTIC attribute is not recognized, ignore the
attribute because its type indicates that it is comprehension- attribute because its type indicates that it is comprehension-
optional. This should be the existing behavior as explained in optional. This should be the existing behavior as explained in
section 3.1 of [RFC5389]. section 3.1 of [RFC5389].
o The server that supports PATH-CHARACTERISTIC attribute MUST echo o The server that supports PATH-CHARACTERISTIC attribute MUST echo
back ReTransCnt in the response. back ReTransCnt in the response.
o If the server is stateless or does not want to remember the o If the server is stateless or does not want to remember the
transaction ID then it would populate value 0 for the ReqTransCnt transaction ID then it would populate value 0 for the RespTransCnt
and RespTransCnt fields in PATH-CHARACTERISTIC attribute sent in field in PATH-CHARACTERISTIC attribute sent in the response. If
the response .If the server is stateful then it populates the server is stateful then it populates RespTransCnt with the
ReqTransCnt with the number of times it received the STUN request number of responses it has sent for the STUN request.
with the same transaction ID and RespTransCnt with the number of
responses it has sent for the STUN request.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| ReTransCnt | | Reserved, should be 0 | ReTransCnt | RespTransCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ReqTransCnt | RespTransCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PATH-CHARACTERISTIC attribute in response Figure 2: PATH-CHARACTERISTIC attribute in response
The fields are described below: The fields are described below:
ReTransCnt: Copied from request. ReTransCnt: Copied from request.
ReqTransCnt: Number of times request is received from the client
with the same transaction ID.
RespTransCnt: Number of responses sent to the client for the same RespTransCnt: Number of responses sent to the client for the same
transaction ID. transaction ID.
3.3. Example Operation 3.3. Example Operation
The operation is described in Figure 3. In the first case, all the The operation is described in Figure 3. In the first case, all the
requests and responses are received correctly. In the upstream loss requests and responses are received correctly. In the upstream loss
case, the first request is lost, but the second one is received case, the first request is lost, but the second one is received
correctly, the client on receiving the response notes that while 2 correctly, the client on receiving the response notes that while 2
requests were sent, only one was received by the server, also the requests were sent, only one was received by the server, also the
skipping to change at page 6, line 44 skipping to change at page 6, line 41
1,1 | | x | | 1,1 | | x | |
2 2,2 | 2 2,1 | 2 2,2 | 2 2,1 | 2 2,2 | 2 2,1 | 2 2,2 | 2 2,1 |
2,2 | 2,1 | x | x | 2,2 | 2,1 | x | x |
3 3,3 | 3 3,2 | 3 3,3 | 3 3,2 | 3 3,3 | 3 3,2 | 3 3,3 | 3 3,2 |
3,3 | 3,2 | 3,3 | 3,2 | 3,3 | 3,2 | 3,3 | 3,2 |
Figure 3: Retransmit Operation between client and Server Figure 3: Retransmit Operation between client and Server
4. Usecases 4. Usecases
The STUN attribute defined in this specification can be used by The STUN attribute defined in this document can be used by
applications in the following scenarios: applications in the following scenarios:
o When an endpoint has multiple interfaces (for example 3G, 4G, o When an endpoint has multiple interfaces (for example 3G, 4G,
WiFi, VPN, etc.), an ICE agent can choose the interfaces for media WiFi, VPN, etc.), an ICE agent can choose the interfaces for media
streams according to the path characteristics. After STUN streams according to the path characteristics. After STUN
responses to STUN checks are received, the ICE agent using regular responses to STUN checks are received, the ICE agent using regular
nomination can sort the ICE candidate pairs according to the path nomination can sort the ICE candidate pairs according to the path
characteristics (loss and RTT) discovered using STUN. The characteristics (loss and RTT) discovered using STUN. The
controlling agent can then assign the highest priority to controlling agent can then assign the highest priority to
candidate pair which best fulfills the desired path candidate pair which best fulfills the desired path
skipping to change at page 7, line 18 skipping to change at page 7, line 15
an endpoint needs to pick paths based on capacity, it would have an endpoint needs to pick paths based on capacity, it would have
to send media on those paths. to send media on those paths.
o When a host has multiple interfaces available an MPRTP o When a host has multiple interfaces available an MPRTP
[I-D.ietf-avtcore-mprtp] application can choose the interfaces for [I-D.ietf-avtcore-mprtp] application can choose the interfaces for
the corresponding subflows according to the path characteristics the corresponding subflows according to the path characteristics
discovered using STUN. For example, the scheduling algorithm discovered using STUN. For example, the scheduling algorithm
described in [ACM-MPRTP] uses path capacity, latency, and loss described in [ACM-MPRTP] uses path capacity, latency, and loss
rate for choosing the most suitable subset of paths. rate for choosing the most suitable subset of paths.
o The STUN extension proposed in this specification can also be used o The STUN extension proposed in this document can also be used to
to choose a TURN server that provides the best user experience choose a TURN server that provides the best user experience
(section 3.1 of [I-D.patil-tram-turn-serv-selection]). (section 3.1 of [I-D.patil-tram-turn-serv-selection]).
5. IANA Considerations 5. IANA Considerations
[Paragraphs in braces should be removed by the RFC Editor upon [Paragraphs in braces should be removed by the RFC Editor upon
publication] publication]
[The PATH-CHARACTERISTIC attribute requires that IANA allocate a [The PATH-CHARACTERISTIC attribute requires that IANA allocate a
value in the "STUN attributes Registry" from the comprehension- value in the "STUN attributes Registry" from the comprehension-
optional range (0x8000-0xFFFF), to be replaced for TBD-CA throughout optional range (0x8000-0xFFFF), to be replaced for TBD-CA throughout
skipping to change at page 8, line 9 skipping to change at page 8, line 7
between peers using ICE, and ICE uses STUN short-term credential between peers using ICE, and ICE uses STUN short-term credential
mechanism the risk of on-path attack influencing the messages is mechanism the risk of on-path attack influencing the messages is
minimal. However, an attacker could corrupt, remove, or delay an ICE minimal. However, an attacker could corrupt, remove, or delay an ICE
request or response, in order to discourage that path from being request or response, in order to discourage that path from being
used. Unauthenticated STUN message MUST NOT include the PATH- used. Unauthenticated STUN message MUST NOT include the PATH-
CHARACTERISTIC attribute in order to prevent on-path attacker from CHARACTERISTIC attribute in order to prevent on-path attacker from
influencing decision-making. influencing decision-making.
7. Acknowledgements 7. Acknowledgements
Thanks to Brandon Williams, Simon Perreault, Aijun Wang for valuable Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin
inputs and comments. Thomson and Oleg Moskalenko for valuable inputs and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
skipping to change at page 8, line 46 skipping to change at page 8, line 44
Singh, V., Karkkainen, T., Ott, J., Ahsan, S., and L. Singh, V., Karkkainen, T., Ott, J., Ahsan, S., and L.
Eggert, "Multipath RTP (MPRTP)", draft-ietf-avtcore- Eggert, "Multipath RTP (MPRTP)", draft-ietf-avtcore-
mprtp-00 (work in progress), December 2014. mprtp-00 (work in progress), December 2014.
[I-D.patil-tram-turn-serv-selection] [I-D.patil-tram-turn-serv-selection]
Patil, P., Reddy, T., and G. Salgueiro, "Traversal Using Patil, P., Reddy, T., and G. Salgueiro, "Traversal Using
Relays around NAT (TURN) Server Selection", draft-patil- Relays around NAT (TURN) Server Selection", draft-patil-
tram-turn-serv-selection-00 (work in progress), October tram-turn-serv-selection-00 (work in progress), October
2014. 2014.
[I-D.uberti-mmusic-nombis]
Uberti, J. and J. Lennox, "Improvements to ICE Candidate
Nomination", draft-uberti-mmusic-nombis-00 (work in
progress), March 2015.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: tireddy@cisco.com Email: tireddy@cisco.com
Dan Wing Dan Wing
skipping to change at page 9, line 31 skipping to change at page 9, line 34
Paal-Erik Martinsen Paal-Erik Martinsen
Cisco Systems, Inc. Cisco Systems, Inc.
Philip Pedersens vei 22 Philip Pedersens vei 22
Lysaker, Akershus 1325 Lysaker, Akershus 1325
Norway Norway
Email: palmarti@cisco.com Email: palmarti@cisco.com
Varun Singh Varun Singh
Nemu Dialogue System Oy Nemu Dialogue System Oy
Espoo 02235 Itaemerenkatu 5
Helsinki 00150
Finland Finland
Email: varun@callstats.io Email: varun@callstats.io
 End of changes. 22 change blocks. 
65 lines changed or deleted 68 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/