Re: [dccp] DCCP-over-UDP [was draft-phelan-dccp-natencap-00.txt]
Hi, There has been a lot of talk in this thread about DNS. I want a solution that works without DNS. If one uses SIP or RTSP to establish a media pat using DCCP. In most cases one do include the explicit IP address rather than the FQDN. Thus no DNS queries etc. I think something that makes this work on the same port is desirable. Cheers Magnus Phelan, Tom skrev: Hi Dan, Thanks for the detail in this and your previous message. I agree that this is worthwhile to explore for the next version of dccp-natencap and it'll give me a good head start on working things out. Tom P. -Original Message- From: Dan Wing [mailto:[EMAIL PROTECTED] Sent: Saturday, February 23, 2008 1:03 PM To: [EMAIL PROTECTED] Cc: Phelan, Tom; 'Colin Perkins'; ''dccp' working group' Subject: RE: [dccp] DCCP-over-UDP [was draft-phelan-dccp-natencap-00.txt] Can you explain why 100ms seems reasonable? Longer than that would become noticable in those cases where DCCP-RAW was being blocked. I commonly use paths that have much longer delays than this, and would have expected native DCCP/IP encapsulation to still be used in these cases, rather than defaulting to an encapsulated format. The algorithm I am proposing would still achieve that. The algorithm I am proposing has you send a DCCP-RAW request and wait 100ms for a response. If no DCCP-RAW response is received in that 100ms, you then try DCCP-UDP. You do _not_ abandon the DCCP-RAW connection attempt, however. This will provide you with a DCCP-RAW connection even over 100ms round-trip delay paths. I agree that if the first DCCP-RAW request is dropped (due to network congestion or other reasons) you may, for that connection, end up with DCCP-UDP (assuming the DCCP-UDP request and its response are not dropped). I don't see a solution to that problem, other than waiting a really long time for the DCCP-RAW to fail. Waiting a really long time for DCCP-RAW to fail will make DCCP-UDP seem very slow at connection establishment, and I will cause DCCP-UDP connection setup to be perceived as 'slow' by users and user applications. The case with no middlebox (NAT or firewall): DCCP client DNS serverDCCP server --- ----- | | | | DNS SRV?-| | | DNS A?---| | |--- DNS SRV --| | (not used)|--- DNS A - --| | |--- DCCP-RAW request-| (wait 100ms) |--- DCCP-UDP request | |--- DCCP-RAW response ---| (continue with DCCP-RAW connection) |--- DCCP-UDP response ---| (this DCCP-UDP response isn't needed, so abort it) |--- DCCP-UDP close --| | | | with a middlebox: DCCP client middleboxDNS serverDCCP server --- ------ | | | | | DNS SRV?-| | | DNS A?---| | |--- DNS SRV --| | (not used)|--- DNS A - --| | |---X | | (wait 100ms) | | | |--- DCCP-UDP request | |--- DCCP-UDP response ---| (continue with DCCP-UDP connection) | | | | | | -d -- Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] --
Re: [dccp] draft-phelan-dccp-natencap-00.txt
Hi, one question we really need to answer is whether we want to go through the pains of specifying UDP encapsulations for all our transport protocols. We have on the table: * draft-phelan-dccp-natencap for DCCP * draft-tuexen-sctp-udp-encaps for SCTP * JDR's recent email on the MMUSIC list for TCP-over-UDP All of them need to basically design very similar handshake/signaling exchanges, they all need a solution for the service identification issue, etc. This is undesirable. If we need to encapsulate something in UDP for the purposes of NAT traversal, why aren't we encapsulating IP in UDP, on top of which we can run pretty much anything? Instead of requiring that DCCP stacks grow support for DCCP-over-UDP, why don't we simply require that DCCP stacks implement Teredo or something similar? Why are we solving the NAT traversal problem protocol-by-protocol rather than one time? (The still ongoing NAT traversal discussion in HIP - which is building its own NAT traversal solution - has left me convinced that we should have pushed harder for the original just use Teredo proposal for HIP NAT traversal. We'd be long done.) Lars
[dccp] Draft Agenda now available for IETF-71
I've uploaded a draft agenda at: https://datatracker.ietf.org/meeting/71/materials.html If you are listed as a presenter and have not yet contacted the Chairs - please email us as soon as possible:-) If you have slides ready, then please do send them. (Please send by noon Monday 10th at the very latest - there will be remote participants at this meeting and they need the slides before the session). If you'd like to present and are not currently listed, please let us know, Best wishes, Gorry Tom
[dccp] Fwd: I-D Action:draft-ietf-dccp-rfc3448bis-05.txt
I have submitted a revised version of draft-ietf-dccp-rfc3448bis-05.txt. The changes from -04 are as follows: * Added a mechanism for decaying the value in X_recv_set following a loss event in a data-limited interval, and restricting recv_limit to max (X_recv_set) for the next RTT. Also added a discussion to Appendix C of the response to a loss during a data-limited period. Following feedback from Gorry and Arjuna. * Removed a restriction in step 4) of Section 4.3 about checking if the sender was not data-limited, when the sender has been in initial slow-start. It is no longer needed. Feedback from Arjuna. * Added pseudocode to Section 8.2.1 on Determining If an Interval Was a Data-limited Interval, fixing a bug in the procedure. Feedback from Arjuna. Many thanks to Gorry and Arjuna for feedback, in particular about dealing with loss events in data-limited intervals. I think this is now ready for Working Group Last Call (though I note that I have thought this before...) - Sally http://www.icir.org/floyd/ Begin forwarded message: From: [EMAIL PROTECTED] Date: February 25, 2008 10:30:01 AM PST To: [EMAIL PROTECTED] Cc: dccp@ietf.org Subject: [dccp] I-D Action:draft-ietf-dccp-rfc3448bis-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Datagram Congestion Control Protocol Working Group of the IETF. Title : TCP Friendly Rate Control (TFRC): Protocol Specification Author(s) : U. London, et al. Filename: draft-ietf-dccp-rfc3448bis-05.txt Pages : 64 Date: 2008-02-25 This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dccp-rfc3448bis-05.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-ietf-dccp-rfc3448bis-05.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-ietf-dccp-rfc3448bis-05.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: [EMAIL PROTECTED]
Re: [dccp] New revision of The DCCP Service Code
Gorry, comments on service-codes-04. The original draft of the DCCP specification did not use traditional ports; instead the client allocated a 32-bit identifier to uniquely identify the connection. ... This design suffered from the downside of being sufficiently different from existing protocols that there were concerns that it would hinder the use of DCCP through NATs and other middleboxes. An additional downside is that this design prevents the deployment of two servers for the same service on a single machine, something that is trivial with ports. This is the true reason why ports reappeared, although NAT/middlebox concerns also played a part. This permits a flexible correspondence between services and port numbers than possible using the corresponding socket pair (4-tuple of layer-3 addresses and layer-4 ports). a MORE flexible correspondence Note that more than one DCCP server may share the same server port, since in DCCP the Service Code mechanism is the method for unique identification of a service. This is not correct: the COMBINATION of server port and Service Code uniquely identifies a LISTENING APPLICATION. It is important to get this right. 2.7. A method to hash the Service Code to a Dynamic Port I do not find this section convincing. Among other things: - operating systems use the dynamic port range for client ports, and therefore there is a chance that a server attempting to open the indicated port for listening will be prevented from doing so because of an existing short-lived client port. - the function can return port 65535 which i believe some OSes refuse to open - there is no need for a large range of server ports (because of the unique mapping of server port + service code to application). - the section is unclear whether it is suggesting a possible procedure or defining a requirement. I suggest instead that the document allocate one Registered Port intended for use by DCCP applications with no port allocation of their own. This port would become something like a default DCCP port, and applications using it would be using the originally intended service code model. If because of current OS constraints (such as the Linux implementation's) more than one default DCCP port is required, that is too bad, but a small range of, say, 256 or 1024 Registered Ports would suffice in practice until that implementation limitation is overcome. Port numbers and IP addresses are the traditional methods to identify a flow within an IP network. When the DCCP header has not been encrypted, Middleboxes [RFC3234] should use the Service Code to identify the application-service (even when running on a non-standard port). When consistently used, the Service Code can provide a more specific indication of the actual service (e.g. indicate the type of multimedia flow, or intended application behaviour). Middlebox devices are therefore expected to check Service Code values as well as, or even instead of port numbers for DCCP. I disagree with this paragraph. It puts requirements on middleboxes and recommends shifting away from well-known practices (e.g., port numbers) to unknown practices with few practical benefits (Service Codes cannot be trusted). are therefore expected is too strong. There are good reasons to manage DCCP applications based on ports, including familiarity. The most I would say is something like Middleboxes that use DCCP may additionally use the Service Code to identify an application service, even when running on a non-standard port. When consistently used, the Service Code can provide a specific hint of the intended service, such as the type of multimedia flow or intended application behavior. Additional text, if any, should explain WHY middleboxes should shift towards using the Service Code; this would be more convincing and appropriate than the current requirement. This section would be more useful if it pointed out to middlebox authors some issues with port numbers. For example: Middlebox authors are cautioned that new DCCP connections are identified by the pair of Server Port and Service Code. In particular, this means that IANA may allocate a server port to more than one application. All such applications will be distinguished by Service Code. A middlebox that intends to differentiate applications SHOULD therefore test the Service Code as well as the destination or source port on a DCCP-Request or DCCP-Response packet. Security Consideration: DCCP's use of Service Codes as well as ports to demultiplex incoming connections may change the service model expected by middleboxes. The port-numbers registry already contains some instances of multiple application registrations for a single port number for TCP and UDP. This is relatively rare, however. Since DCCP's Service Code allows multiple applications to safely share the
Re: [dccp] draft-phelan-dccp-natencap-00.txt
Hi Lars, I sympathize with your concern for each transport inventing its own UDP encap solution. However, I don't think that that IP/UDP/IP/DCCP[SCTP][whatever] works well. What is in the inner IP addresses? They're not useful at all. They could start out the same as the outer addresses, but after traversing a NAT they wouldn't make sense to the receiving system. Can we invent a generic transport UDP encapsulation? Maybe, maybe not. I haven't seen that TCP-over-UDP thing. What kind of rationale is there for that? Tom P. -Original Message- From: Lars Eggert [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 10:19 AM To: Phelan, Tom Cc: 'dccp' working group Subject: Re: [dccp] draft-phelan-dccp-natencap-00.txt Hi, one question we really need to answer is whether we want to go through the pains of specifying UDP encapsulations for all our transport protocols. We have on the table: * draft-phelan-dccp-natencap for DCCP * draft-tuexen-sctp-udp-encaps for SCTP * JDR's recent email on the MMUSIC list for TCP-over-UDP All of them need to basically design very similar handshake/signaling exchanges, they all need a solution for the service identification issue, etc. This is undesirable. If we need to encapsulate something in UDP for the purposes of NAT traversal, why aren't we encapsulating IP in UDP, on top of which we can run pretty much anything? Instead of requiring that DCCP stacks grow support for DCCP-over-UDP, why don't we simply require that DCCP stacks implement Teredo or something similar? Why are we solving the NAT traversal problem protocol-by-protocol rather than one time? (The still ongoing NAT traversal discussion in HIP - which is building its own NAT traversal solution - has left me convinced that we should have pushed harder for the original just use Teredo proposal for HIP NAT traversal. We'd be long done.) Lars
