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]
----------------------------------------------------------------------
