> Hi Colin, > > [snipped] > > Sure, but is it needed? If you want DCCP-over-UDP > > encapsulation to be > > seamless, then surely you need to try it every time a native > > connection attempt fails. In that case, there's no need for separate > > signalling. > > I have a problem with this thought of failing over -- how long is it > going to take? I see the desirability of this kind of seamless > operation, but it's going to take some thought to come up > with a method > of doing it that doesn't have serious drawbacks.
Here is something interesting, which I am familiar with from second hand information -- my Mac doesn't run a modern version of Safari and is too slow to try to upgrade it. But: As part of Apple's support of DNS Service Discovery, Safari sends out DNS queries for both SRV records and A records. There is some amount of time that Safari waits for the SRV response before it issues the A query. The purpose of Safari's function is to provide a backward-compatible way to introduce SRV records: if the host you are contacting has an SRV record, Safari will use it. If the host doesn't have an SRV record but only has an A record, Safari will use the A record. Of course, on today's Internet, almost everything has only an A record and very few things have an SRV record. For DCCP, if we pursue this idea of using SRV records to indicate support for DCCP-RAW and DCCP-UDP, we could just issue SRV queries. This is the benefit of not having a legacy of A records. But when a DCCP client does a SRV query for DCCP-RAW and DCCP-UDP, and gets back both answers, the DCCP client does not know -- and can not know -- if DCCP-RAW will work. So the DCCP client would need to perform a connection initiation for DCCP-RAW and another connection initiation for DCCP-UDP. How those are split apart is something we would need to decide on, especially how quickly they could be attempted without causing harm to TCP friendliness. One might argue they should be sent 2 seconds apart, but that would not build a community of interest around DCCP if, when traversing a DCCP-unaware NAT, it takes an additional 2 seconds for DCCP-UDP to initiate a connection versus, say, TCP. So we need something more aggressive. I don't know how aggressive we could be. We could steal some ideas from ICE, which does something somewhat similar. ICE paces its various retries to consume no more bandwidth than the RTP flow that will (eventually) be running over that connection. Unfortunately, with DCCP, DCCP doesn't really know the size of the flow that will eventually be sent, and DCCP needs to be more TCP friendly than RTP (and thus ICE) are, too. But I'm sure some value can be reached; I am hoping something in the 100ms range or so, which doesn't cause DCCP-UDP to appear too pokey to users, but still allows enough time for nearly any DCCP-RAW connection to work if it's going to work. -d
