I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised.
The purpose of the mechanisms described is to transfer media streams,
likely based on RTP, between devices. This is done using SLP to
discover devices, followed by a SIP exchange to negotiate new (RTP)
media streams. The use of SLP and SIP does not appear to offer
concern from a transport perspective (I have not reviewed it for
correctness from an SLP or SIP perspective).
The main transport concern with this draft is with how to ensure
retargeted RTP streams don't congest the new network path. The draft
touches on this issue in Section 6, hinting that application-level
measures may be used to adjust, but it's not clear that is
sufficient. An ideal response to ensure congestion safety would be to
slow-start on the new path, but that's also problematic since it
would unnecessarily disrupt the media on paths that can sustain the
required rate. Given these conflicting constraints, the best solution
we have available might be to signal the new link capacity in the SIP
exchange if the bottleneck bandwidth is known, and be prepared to
react to congestion within a small number of round-trip times (e.g.
perhaps using early RTCP, or transport-level feedback to signal the
need to adapt). The draft should include more discussion of these
issues, and the potential solutions.
Section 5.2.1.2 implies that the connections for real-time media do
not need to be established before use. This is not the case if
comedia (RFC 4145) is used, e.g. for RTP streams running over TCP,
TLS, or DCCP. The order of connection setup should be addressed.
The draft seems to ignore the presence of NAT boxes which might
disrupt media connectivity. An ICE exchange will likely be needed to
work around this during handover. At what point in the call flows
should this be done? Similarly, the RTPSEC work is considering media-
path keying for SRTP (e.g. DTLS or ZRTP), which also needs to be done
during the handover, but is not mentioned.
None of these are not insurmountable problems, but they should be
addressed before the draft is ready for publication.
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
