Subject: tsv-dir review of draft-shacham-sipping-session-mobility-03.txt

From: Colin Perkins <[email-masked]>
Date: Tue, 8 May 2007 23:23:48 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf