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
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
-ietf-dccp-
rtp-04-from-03.diff.html
I believe this is now ready for WG last call.
--
Colin Perkins
http://csperkins.org/
will require a sender to
send
--
Colin Perkins
http://csperkins.org/
traffic, the ability to restart an idle
connection, and power consumption.
--
Colin Perkins
http://csperkins.org/
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.
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.
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.
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/
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/
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,
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/
, 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-
From: Colin Perkins [mailto:[EMAIL PROTECTED]
Sent: Sunday
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
delay, but I agree that some careful thought is needed to get it right.
--
Colin Perkins
http://csperkins.org/
response allows an information leak - something is
listening on the port - which some servers may wish to avoid.
Cheers,
--
Colin Perkins
http://csperkins.org/
-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/
) middleboxes without
modification of those middleboxes.
The IETF Secretariat.
--
Colin Perkins
http://csperkins.org/
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-
natencap-03
Tom
prefer we get this
right, than preserve running code that has minimal deployment.
--
Colin Perkins
http://csperkins.org/
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/
.
--
Colin Perkins
http://csperkins.org/
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/
-
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 Internet-Draft
. This documents also updates the
SDP information for DCCP defined in RFC 5762.
The IETF Secretariat.
--
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 receipt; the UDP ports would be used
them off for encapsulating.
E
On 12/20/10 1:50 AM, Pasi Sarolahti wrote:
On Dec 15, 2010, at 11:20 PM, Colin Perkins wrote:
No, they would not. Just as the encapsulated DCCP header checksum is
ignored, the encapsulated DCCP PORTS would be ignored. The receiver
would use the ports
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/
: 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:
On Jan 19, 2011, at 9:40 PM, Gorry Fairhurst wrote
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, Eddie Kohler wrote:
Colin,
The problem solved by the 6-tuple is that the receiver CANNOT
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
On 02/07/2011 08:29 AM, Colin Perkins wrote:
I'm well aware of the example. It's one
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 c...@csperkins.org
wrote:
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
On 19 May 2011, at 12:54, Rémi Denis-Courmont wrote:
On Wed, 18 May 2011 07:24:19 +0100, Colin Perkins c...@csperkins.org 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
normative
33 matches
Mail list logo
