Hi Magnus, I agree completely with not *requiring* DNS.
Tom P. > -----Original Message----- > From: Magnus Westerlund [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 26, 2008 9:01 AM > To: Phelan, Tom > Cc: Dan Wing; [EMAIL PROTECTED]; 'dccp' working group; Colin Perkins > Subject: 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 server DCCP 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 middlebox DNS server DCCP 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] > ----------------------------------------------------------------------
