On 7 Mar 2006, at 09:46, Lars Eggert wrote:
...
PS: Good news from the RFC editor - the spec, both CCIDs and the
problem statement have just hit AUTH48.
One minor nit I noticed while updating the RTP-over-DCCP draft, which
it might be possible to fix in AUTH48. Section 8.1.2 states:
SC
A new version of the RTP-over-DCCP draft is available. Changes include:
- Extensive editorial changes and clarifications
- Clarify that the DCCP connection remains open for the duration of the
RTP session.
- Update discussion of multiplexed RTP and RTCP in section 4.3
- Clarify signalling of th
Arne,
On 13 Mar 2006, at 14:34, Arne Lie wrote:
I am performing experiments with VBR rate controlled video over
TFRC (in
ns-2.28). [I have also noticed the VoIP initiative in DCCP, to cope
with
silent periods etc., so I believe that my findings could be
"compliant" to
the motivation behind
The draft on running RTP over DCCP has been updated. The main change
has been to rework the discussion of how RTCP and DCCP congestion
control interact. There have also been minor changes to clarify use
of zero-length DCCP-Data packets as keep-alives, to fix the ABNF, and
to register DCCP p
Gorry,
On 3 Jul 2006, at 11:54, Gorry Fairhurst wrote:
Thanks, we should definitely discuss this in the meeting next week.
Some comments from a read of the new rev of this draft are below,
...
* In Section 4.2, you note that the action depends on the actual
time an
RTCP packet is sent, how
Hi Tom,
On 11 Jul 2006, at 13:40, Phelan, Tom wrote:
A couple of comments/questions on RTP/DCCP (excuse me if I'm asking
questions I asked before, but if I did, I'm still unclear on the
answers):
Section 4.1 has a todo about supplying more direction on the
implementation of congestion control i
On 17 Jul 2006, at 20:50, [EMAIL PROTECTED] wrote:
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 : RTP and the Datagram Congestion Contro
On 23 Oct 2006, at 23:50, [EMAIL PROTECTED] wrote:
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 : RTP and the Datagram Congestion Control
On 5 Nov 2006, at 19:44, Gorry Fairhurst wrote:
Colin, I have just a few queries (mainly wording) about your I-D.
Best wishes,
Gorry
---
In Section 4.2, you don't define or reference SIP when first used:
" for example by performing a SIP re-invite..."
- Perhaps say: "Session Initiation Pro
On 8 Nov 2006, at 10:50, Sally Floyd wrote:
The minutes are attached, this time in a file with a *.txt name...
One follow-up:
Colin: RTP and the DCCP draft.
There are no known open issues.
Question: Is Colin going to present this in AVT tomorrow morning?
He doesn't know, but he will present i
On 16 Nov 2006, at 20:50, [EMAIL PROTECTED] wrote:
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 : RTP and the Datagram Congestion Control
On 1 Dec 2006, at 12:38, Mark Handley wrote:
I agree that running a very small no-feedback timer is a bad idea.
But I think that 1 second is probably far too large. The purpose of
the nofeedback timer is to slow DCCP down when there is serious
network congestion. Waiting 1 second on a LAN would
/draft-ietf-dccp-rtp/draft-ietf-dccp-
rtp-04-from-03.diff.html
I believe this is now ready for WG last call.
--
Colin Perkins
http://csperkins.org/
ent if it is known that the DCCP CCID in use
provides a
! transport level keepalive.
RTP data packets MUST obey the dictates of DCCP congestion
control.
In some cases, the congestion control will require a sender to
send
--
Colin Perkins
http://csperkins.org/
the amount of keep alive traffic, the ability to restart an idle
connection, and power consumption.
--
Colin Perkins
http://csperkins.org/
which use DCCP, but don't try to second-guess.
--
Colin Perkins
http://csperkins.org/
On 27 Mar 2007, at 17:06, Gorry Fairhurst wrote:
So,
From all the thread so far
* I have some ideas of what RTP-like applications want. I'm not
sure there is a need to send/receive a 0-byte Data packet as a way
to make keep-alives happen.
The applications I care about need a way to send p
On 28 Mar 2007, at 08:09, Gorry Fairhurst wrote:
...
Applications that want keepalives should define some corresponding
data format: a one-byte datagram would suffice.
Not sure I agree, I'd rather the apps called-down to the transport
using a control function and asked them to do this.
I'm
On 28 Mar 2007, at 16:04, Eddie Kohler wrote:
Colin Perkins wrote:
On 28 Mar 2007, at 08:09, Gorry Fairhurst wrote:
...
Applications that want keepalives should define some
corresponding data format: a one-byte datagram would suffice.
Not sure I agree, I'd rather the apps called-down t
On 11 Apr 2007, at 23:45, Ian McDonald wrote:
On 4/12/07, Gerrit Renker <[EMAIL PROTECTED]> wrote:
There is no way to stop a Linux CCID3 sender from ramping X up to
the link bandwidth of 1 Gbit/sec; but the scheduler can only
control packet pacing up to a rate of s * HZ bytes per second.
Le
On 20 Apr 2007, at 11:20, Ian McDonald wrote:
On 4/20/07, Gerrit Renker <[EMAIL PROTECTED]> wrote:
Ian, I would appreciate if in future you would not copy patch
descriptions over from [EMAIL PROTECTED] to [EMAIL PROTECTED]
Apart from the fact that I don't like it, this creates the wrong
idea
On 20 Apr 2007, at 12:31, Gerrit Renker wrote:
| Likewise - we have experiments in progress, and while we do have
| stability problems with our TFRC implementation, I'm unconvinced
the
| behaviour is due to the reasons suggested. I'll report back when we
| have more results.
|
I am not sur
On 3 May 2007, at 14:34, Phelan, Tom wrote:
This is to announce the beginning of a working group last call for
draft-ietf-dccp-rtp-05.txt, "RTP and the Datagram Congestion Control
Protocol (DCCP)" (available at
http://www.ietf.org/internet-drafts/draft-ietf-dccp-rtp-05.txt.
Thanks!
PS. Co
lin -- one nit comment I see as I prepare this e-mail -- you
apparently felt the need to expand the DCCP acronym in the title, but
not RTP. I guess that shows where your familiarity lies :-). At any
rate, I recall some long-past discussion about how all acronyms in
titles should be expanded...
--
Colin Perkins
http://csperkins.org/
[Inline; Jonathan - see ICE discussion below]
On 10 May 2007, at 18:36, Lars Eggert wrote:
On 2007-5-3, at 5:34, ext Phelan, Tom wrote:
This is to announce the beginning of a working group last call for
draft-ietf-dccp-rtp-05.txt, "RTP and the Datagram Congestion Control
Protocol (DCCP)" (avail
On 11 May 2007, at 15:36, Magnus Westerlund wrote:
Some WG last call comments:
A. Section 4.4:
In the case an RTP session bridges multiple DCCP connections it
might be worth noting that support of TMMBR from draft-ietf-avt-ccm
could help. I would suggest including an informative reference to
On 11 May 2007, at 19:18, Lars Eggert wrote:
On 2007-5-11, at 1:16, ext Colin Perkins wrote:
On 10 May 2007, at 18:36, Lars Eggert wrote:
Section 4.2., paragraph 1:
>The RTP Control Protocol (RTCP) is used in the standard
manner with
>DCCP. RTCP packets are grouped into co
On 21 May 2007, at 10:03, Lars Eggert wrote:
On 2007-5-17, at 20:53, ext Phelan, Tom wrote:
Aren't the default NAT timeouts for UDP and TCP different -- UDP
has to
be short because there's no other way to tell that a connection is no
longer needed -- TCP can be longer because what the timeout
cept
the keep-alive timer. As I said, I'd prefer to leave the timer as-is,
but if there is consensus to use a larger timer, I'm happy to submit
an update to address that.
--
Colin Perkins
http://csperkins.org/
pplications SHOULD register and use a service code specific to the
application.
To the application, or to the protocol? The RTP-over-DCCP draft uses
service codes specific to the protocol, for example.
--
Colin Perkins
http://csperkins.org/
ternet-Draft is:
http://www.ietf.org/internet-drafts/draft-jennings-sip-dtls-04.txt
--
Colin Perkins
http://csperkins.org/
^^^
SHOULD be used whenever an alternative DCCP port is used.
^^^^^^^^^
Makes sense - I'll add this.
Cheers,
--
Colin Perkins
http://csperkins.org/
On 11 Jun 2007, at 19:59, Gorry Fairhurst wrote:
The form of the IANA line to update the registry should normatively
be a big-endian 32-bit number (RFC 4340, 19.8), the 4 character
ascii is an alternative represenation.
3. I believe the draft needs to define a value for its IANA-
registe
Eddie,
On 11 Jun 2007, at 20:49, Eddie Kohler wrote:
Better late than never, perhaps; some comments on RTP over DCCP.
The draft is clear and really well written which is awesome.
Thanks!
In Section 5.2, you might point out that a given Service Code may
be specified in many ways. RTP proce
, for example if a DCCP session starts
insecure, then switches to DTLS after application level negotiation
to determine whether the peer supports DTLS, what would be an
appropriate service code?
--
Colin Perkins
http://csperkins.org/
Tom,
Thanks for looking into this - I'm glad to see there are no issues.
I've cc'd the authors of the DTLS-SRTP draft, in case they wish to
add a paragraph on transport issues, noting that DTLS-SRTP should
work over UDP and DCCP alike.
Cheers,
Colin
On 16 Oct 2007, at 18:41, Phelan, To
item 2: isn't clear why this is split into 2a and
2b. Is the only difference that 2a includes the possibility that this
is a regular expiration of the time?
Section 6.3.1, last paragraph on page 33, should:
"X_target by the maximum X_rec so far, for X_recv the receive rate" be
"X_target by the maximum X_recv so far, where X_recv is the receive
rate"
^ ^^^
--
Colin Perkins
http://csperkins.org/
x27;s not at
all clear to me that such a thing is a good idea - then I'd recommend
that we do so in a way that it can be done by the DCCP stack,
transparently to the applications, with a well-defined order for
trying native vs. encapsulated connection requests.
--
Colin Perkins
http://csperkins.org/
that
breaks
DCCP into wild (or even initial) success, but I do believe it will
make
early experimentation easier and will be necessary (but not
sufficient)
for eventual initial success.
As far as the second issue, I'll put that in another e-mail.
Tom P.
-Original Message
On 19 Feb 2008, at 18:43, Dan Wing wrote:
...
DCCP has an initiation handshake. It seems effective, to me,
to define SRV records that are something like this:
_foobar._dccp SRV 0 0 1234 server.example.com.
_foobar._dccp-udp SRV 0 0 1234 server.example.com.
and protocol fo
sible to the SDP
layer, but maybe that won't work.
--
Colin Perkins
http://csperkins.org/
y over
IP, or tunnelled over UDP. Since it's a single transport instance,
the same port space would be used for encodings of the data.
--
Colin Perkins
http://csperkins.org/
to avoid a long
delay, but I agree that some careful thought is needed to get it right.
--
Colin Perkins
http://csperkins.org/
f you make the UDP port
equivalent to the DCCP port, that means you can't have UDP apps. I
don't think that's a workable solution.
Sure - I was agreeing: use a single DCCP port space, no matter
whether native or tunnelled. That only uses one UDP port.
--
Colin Perkins
http://csperkins.org/
t;Connection Refused". Requiring
a Bad Service Code response allows an information leak - something is
listening on the port - which some servers may wish to avoid.
Cheers,
--
Colin Perkins
http://csperkins.org/
ons in parallel for the
DCCP-INIT, and use that which works, rather than applications be
aware of the encapsulation. Wouldn't any choice be a matter of policy
for the OS, not the application?
Cheers,
--
Colin Perkins
http://csperkins.org/
twork Address Translation (NAT) middleboxes without
modification of those middleboxes.
The IETF Secretariat.
--
Colin Perkins
http://csperkins.org/
ome a WG document?
Yes.
In addition, please speak up if you have other technical comments
about the draft.
Thanks!
- Pasi
--
Colin Perkins
http://csperkins.org/
ad to wait for it to be a WG draft. I'll
reapply when/if this gets WG status.
Can you give me more detail for what you'd like to see in the SDP?
Tom P.
-----Original Message-
From: Colin Perkins [mailto:c...@csperkins.org]
Sent: Thursday, November 19, 2009 6:17 AM
To: Phelan,
no way to say "Don't bother trying DCCP_RAW".
Tom P.
-Original Message-
From: Colin Perkins [mailto:c...@csperkins.org]
Sent: Friday, November 20, 2009 11:42 AM
To: Phelan, Tom
Cc: DCCP working group
Subject: Re: [dccp] FW: New Version Notification for
draft-phelan-dccp-
n
than
over IP, the better. I'd greatly prefer the DCCP header to be
identical in both cases, since it simplifies implementations.
--
Colin Perkins
http://csperkins.org/
P that I'd prefer we get this
right, than preserve running code that has minimal deployment.
--
Colin Perkins
http://csperkins.org/
trying to combine
fields to minimize packet size.
DCCP isn't deployed, period. I'd rather see deployment, first, and
efficiency, second.
Agreed.
--
Colin Perkins
http://csperkins.org/
2), or some existing tunnelling scheme
matters less than that we've documented "if you want to encapsulate
DCCP in UDP, do it this way" for interoperability.
--
Colin Perkins
http://csperkins.org/
ariat.
--
Colin Perkins
http://csperkins.org/
e sense to register transports such as
DCCP/UDP/RTP/AVP, rather than using an attribute, to try to solve
these issues? This is possibly something that should be raised in
MMUSIC.
--
Colin Perkins
http://csperkins.org/
riginal Message-
From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf
Of
Colin Perkins
Sent: Wednesday, June 30, 2010 5:13 AM
To: DCCP working group
Subject: Re: [dccp] I-D Action:draft-ietf-dccp-udpencap-01.txt
On 24 Jun 2010, at 20:15, internet-dra...@ietf.org wrote:
A New In
subsequent versions of the draft.
Yes, I support this. It seems like the authors have found a real
problem based on their implementation experience, and the fix seems
sensible.
--
Colin Perkins
http://csperkins.org/
on't be reachable. The draft should note this, and explain
that bi-directional NAT traversal is for future study.
Also, is the title of Section 5.1 accurate? It's not clear that
anything in the new SDP attribute depends on the RTP-over-DCCP
encapsulation.
Cheers,
Colin
--
Colin Perkins
http://csperkins.org/
f I-D, draft-ietf-dccp-udpencap-03.txt has been
>> successfully submitted by Gorry Fairhurst and posted to the IETF
>> repository.
>>
>> Filename: draft-ietf-dccp-udpencap
>> Revision: 03
>> Title: Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT
>> Traversal (DCCP-UDP)
>> Creation_date: 2010-12-08
>> WG ID: dccp
>> Number_of_pages: 12
>>
>> Abstract:
>> This document specifies an alternative encapsulation of the Datagram
>> Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This
>> encapsulation allows DCCP to be carried through the current
>> generation of Network Address Translation (NAT) middleboxes without
>> modification of those middleboxes. This documents also updates the
>> SDP information for DCCP defined in RFC 5762.
>>
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>>
--
Colin Perkins
http://csperkins.org/
> is OK or not. We can update again if there are issues that have not been
> addressed.
>
> Best wishes,
>
> Gorry
--
Colin Perkins
http://csperkins.org/
On 15 Dec 2010, at 21:06, Eddie Kohler wrote:
> On 12/15/2010 01:02 PM, Colin Perkins wrote:
>>> The only way to avoid a 6-tuple is to REQUIRE (with a MUST) that the UDP
>>> ports equal the DCCP ports. In that case, the DCCP ports would be ignored
>>> on packet r
ort for DCCP-UDP'.
> Would it make
> sense to collapse the single subsection so that there is only a section 5?
>
> Section 6: s/swent/sent/, s/encapsualted/encapsulated/,
> s/conenctions/connections/
>
> Section 7: s/occurances/occurrences/
>
> Section 8: s/Collin/C
e, since this is conceptually simplest: the
receiver operation is just to remove the UDP header, and treat the encapsulated
DCCP packet as any other native DCCP packet received. I'd expect this also to
be simple to implement as a user-space daemon.
--
Colin Perkins
http://csperkins.org/
couple the two
port spaces: the UDP port chosen by the encapsulation service is entirely
separate from the DCCP ports. Keep the layers separate as much as possible.
Colin
> Eddie
>
>
> On 2/7/11 3:54 AM, Colin Perkins wrote:
>> On 1 Feb 2011, at 09:02, Pasi Sarolahti wrote:
> destination, DCCP source port, and DCCP destination port.
>
> Hopefully this is enough to jog your memory, there is a worked out example in
> the mail that started all this.
>
> Eddie
>
>
> On 02/07/2011 07:45 AM, Colin Perkins wrote:
>> On 7 Feb 2011, at 15:24, E
ation of a 6-tuple receiver, since the
> described DCCP implementation does not consider UDP ports when looking up
> flows. It describes the operation of an IP-plus-DCCP-ports receiver.
>
> Obviously there is some syntactic problem here, in my brain or in the wording.
>
> Eddie
>
DP description will suffice,
> or whether there is a simple alternative. Please also respond to the DCCP
> list if you wish to discuss this.
>
> Best wishes,
>
> Gorry
--
Colin Perkins
http://csperkins.org/
hat?
If there's agreement that the approach makes sense, them I'll write an example.
--
Colin Perkins
http://csperkins.org/
be
> able to implement this extension to DCCP and I really wonder if anyone
> actually uses it.
What's the concern here? Use the IANA registered port, unless specified
otherwise by the application. Any UDP tunnelling solutions must specify a UDP
port.
--
Colin Perkins
http://csperkins.org/
Rémi,
On 18 May 2011, at 06:22, Rémi Denis-Courmont wrote:
> On Tue, 17 May 2011 21:56:52 +0100, Colin Perkins
> wrote:
>> What's the concern here? Use the IANA registered port, unless specified
>> otherwise by the application. Any UDP tunnelling solutions must specify a
On 19 May 2011, at 12:54, Rémi Denis-Courmont wrote:
> On Wed, 18 May 2011 07:24:19 +0100, Colin Perkins wrote:
>>> It might be that the API makes the problem go away, but that seems like a
>>> risky bet in the absence of any sketch of an API (it would not need to be
>
ft can be found at
>> http://tools.ietf.org/html/draft-ietf-dccp-udpencap-08
>>
>> - Pasi
>>
>> _______
>> mmusic mailing list
>> mmu...@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> ___
> mmusic mailing list
> mmu...@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
--
Colin Perkins
http://csperkins.org/
73 matches
Mail list logo
