FYI: The Linux implementation doesn't even support short sequence numbers
currently, haven't checked the NetBSD one.
- Arnaldo
An even better reason to make 0 the default. Thanks!
E
Hi all,
Here are the other technical corrections, clarifications, and two or
three changes we propose to make in AUTH48 for the DCCP spec.
CORRECTIONS AND CLARIFICATIONS
- Options are explicitly allowed to declare how they behave when
Mandatory.
- The FGSS feature (Section 6.6.4)
Hi all, yay RFCs!
I've turned the DCCP site into a wiki. So if you want to add to the
wiki write me email and I will give you a login.
New link (redirected from old link as well): http://
www.read.cs.ucla.edu/dccp/
Also, implementers may want to examine the diffs between the last
You are neither wrong nor stupid, but I'm not sure that your suggested
algorithm is the best possible fix.
Part of my confusion stems from the fact that I can't quite follow the
example. Where is the idle period? Exactly which packets are sent when?
Also are you measuring X in bytes per
There are a couple issues with the packet size.
This mail will list my understanding of those issues. It has no solutions,
for that there will be another mail.
One thing we have had to consider is that different congestion points in the
network might have different limitations.
Hello; we may have finally got to the root of the confusion.
Section 5.3 of RFC 4342 gives two ways to calculate s, 's=MSS' and average
packet size.
Both choices remain valid.
HOWEVER, the implementation MUST apply its choice consistently. For example,
the application MUST NOT use average
Maybe we should rename the variable s to the nominal packet size instead
of the packet size.
Eddie
Arjuna Sathiaseelan wrote:
Dear Eddie,
Thanks for your reply :). Please see inline:
Hello; we may have finally got to the root of the confusion.
Yes :)
HOWEVER, the implementation
4340 to report. See the attached.
Thanks very much for your work!
Eddie Kohler
Thanks to Alfred Hoenes for reporting several errors in RFC4340.
One technical omission has been found concerning the FGSR and FGSS
variables used to detect reordering of feature negotiation options. We
suggest
We propose to send in the following erratum about RFC 4342 initial
sending rates. Any comments?
RFC 4342, Profile for Datagram Congestion Control Protocol (DCCP)
Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
Reported By: Eddie Kohler, from Arjuna Sathiaseelan
Date:
Section 5
Hi Gorry,
I wouldn't say a range of ports, since that indicates a contiguous
range, which is not what you mean. Otherwise the document seems a fair
distillation of what's in the RFCs.
Thanks!
Eddie
Gorry Fairhurst wrote:
I have a written a new individual I-D to capture all my notes and
I agree with Mark here. The cleanest implementation of the nofeedback
timer would probably not involve actual Linux timers at all! Unless I'm
very confused, the nofeedback timer is only needed to change sending
rates, and thus can safely be checked in the process of sending a packet.
Not
The reason for this is if you are recalculating i_mean based on non
loss you should check after every packet received. However this
involves quite a lot of calculations on linked lists which are CPU
intensive and also stall other processes potentially with locks being
taken. So what I've done is
You shouldn't need to iterate through the list, since i_mean is just
i_tot/w_tot, and w_tot is a constant. You do need to divide, though.
If it makes no difference to you I'd recommend going with the simpler version
-- the logic in dccp_li_hist_recalc_recalcloss is difficult to follow; I
Also, the weights in dccp_li_hist_w appear to be wrong. They should
be 5, 5,
5, 5, 4, 3, 2, 1, not 4,4,4,4,3,2,1,1, according to rfc3448.
I don't believe so. We've done this as per section 8 of RFC3448 and
divide by 4 rather than 5.
Ah yes, never mind.
Eddie
Hi Gerrit,
Strictly speaking one can identify a loss event with a single ECN-marked
packet, so I_0 might be 3, but let that pass. The RFC occasionally
uses lost to mean lost or marked.
The correct answer is simply to subtract X_prev from the sequence number
of the currently received
No, it's not true. If SWL=0 and seqno=2^47+1, then
seqno SWL
in circular 48-bit arithmetic.
[EMAIL PROTECTED] wrote:
Hi all,
In section 7.5.3 of the RFC4340 (Sequence-Validity rules) and in
pseudocode as well (rfc4340, page 96) the following sequence numbers
test is used to make
Hi Ian,
Sorry for the delay in responding.
I agree that the t_ipi implementation sketched in RFC3448 Section 4.6 is
incomplete with respect to slow applications, idle periods, and the like. :(
What follows is a first cut at a solution. Any thoughts from others??
If t_ipi is used to
Hi Gerrit,
In my response to Ian, I proposed a time-based compensation mechanism rather
than a fixed token bucket byte limit. (Please note that I corrected the first
mail.) I think a byte limit of floor(MSS/s) is way too conservative, and any
fixed byte-based compensation mechanism is the
WHOOPSY! I wrote t_ipi when I meant t_nominal, or whatever symbol you choose
for the time the next packet is allowed to be sent. t_ipi should not be
changed; it depends on X_inst.
Eddie Kohler wrote:
If t_ipi is used to schedule transmissions, then the following equation
should be applied
Arjuna:
Arjuna Sathiaseelan wrote:
Dear Eddie,
Thanks for your reply..Ok - the way I saw this problem was like this:
Say the sender is idle for 1.5 RTTs and then sends 2 packets, then
when the feedback is received, then the following part of the
algorithm from Section 4.3 (RFC3448) would be
and not RFC3448...I was raising points from the
RFC3448-bis draft under the presumption that this draft obsoletes
rfc3448 when it comes to implementing in ns-2..
Arjuna
On 2/14/07, Eddie Kohler [EMAIL PROTECTED] wrote:
Arjuna:
Arjuna Sathiaseelan wrote:
Dear Eddie,
Thanks for your reply..Ok - the way
should be managed. I am not clear
from reading this how an update of the TFRC base spec needs to be
treated, is that what you are asking? I note that there are other issues
that also need to be addressed in CCID-3.
Gorry
Eddie Kohler wrote:
I hope Sally and/or Mark speak up here. I'm not sure
Hi Vladimir,
You are right. There is an error. But the buffer SHOULD read as follows:
** +***+ *
12 |0,0|3,0|0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0BN[0]
** +***+ *
^
I would also like to see RFC3448bis include Faster Restart. However,
the two specs serve different purposes and have different half-lives.
RFC3448bis is being pushed towards quick publication as Proposed
Standard, I believe. FR is not suitable for that track. Which will
leave us in the
While I agree with your points, I also feel like we are in a different
situation with TFRCbis, where the delta between TFRCbis and FR might be
measured in months, rather than years
Long live TCP and other dead research,
Eddie
Sally Floyd wrote:
I would also like to see RFC3448bis include
So I think we need to talk about how to/who should use zero-length
packets. It seems to me that the proposed CCID use is wrong. DCCP-Data
packets are for carrying user information -- even if that info is nil.
To use DCCP-Data packets for a DCCP-level purpose seems to pervert that.
CCIDs that
Finally reached the end of the thread.
== FR uses DCCP-Data because FR measures congestion on keepalives.
Congestion on things like Syncs are not measured in the same way, since Syncs
are non-data packets. While DCCP does attempt to measure congestion on
Syncs it charges the congestion to
Tom,
The addition of service codes by DCCP allows us to break this
demultiplexing/identifying duality. We can now say that the *exclusive*
use of port numbers is for demultiplexing, and the *exclusive* use of
service codes is for identifying applications. This implies a few
rules:
We COULD
Colin,
Better late than never, perhaps; some comments on RTP over DCCP.
The draft is clear and really well written which is awesome.
A writing nit: it is generally better not to treat references as nouns;
rather than RTP over TCP, as defined in [5], say RTP over TCP [5].
But this is not that
This sounds like a very interesting idea. While the documents specify that
feedback is sent once per RTT, since this is what TFRC recommends, I think
more frequent feedback is a fine idea even for low-loss-rate/low-RTT scenarios
(twice or four times per RTT, say?), and probably mandatory for
Tom,
I think most of what you write is allowed by, or required by, the current
spec. (As you probably knew.)
Phelan, Tom wrote:
REQ: A DCCP implementation MUST require the using application to
explicitly set the service code associated with a socket before it can
be used in a listen or
Gorry,
Gorry Fairhurst wrote:
Applications/protocols that provide version negotiation or indication
in the protocol operating over DCCP do not require a new server port for
each new protocol version. New versions of such applications/protocols
SHOULD continue to use the same Service Code. If
I'd be fine with a SHOULD.
Eddie
Phelan, Tom wrote:
Hi Eddie,
One question on your comments:
3
= This section explicitly updates RFC 4340 as follows:
A DCCP implementation MUST allow multiple applications using
different DCCP service codes to listen on the same server port.
My immediate goal is to make sure I understand how RFC4340 should be read:
* If my understanding is correct, RFC4340 says exactly ONE application
(we do not indicate which) can be associated with a specific SC of zero
on a particular server port.
Yes.
* Which set of ports do you expect
Gorry Fairhurst wrote:
Eddie Kohler wrote:
snip
SC=0 allows Unix-like implementations to associate a valid Service
Code with every socket, without changing the procedure used for
opening sockets (i.e., without adding extra setsockopt calls or adding
members to struct sockaddr). Linux
I prefer data-limited; any data comes ultimately from an application.
Eddie
Gorry Fairhurst wrote:
Sally Floyd wrote:
Dear Sally,
Just to avoid ambiguity, in 3448-bis, would it be better to change
data-limited to application-limited? This would conforms to RFC2861.
On looking over RFC
Gorry, comments on service-codes-04.
The original draft of the DCCP specification did not use traditional
ports; instead the client allocated a 32-bit identifier to uniquely
identify the connection. ... This design
suffered from the downside of being sufficiently different from
My favorite thing in this new draft is the specific way you have identified
changes to RFC4340. Thanks!
Detailed comments.
Service Codes allow a flexible correspondence between application-
layer services and server port numbers, which affects how
applications interact with DCCP.
P.S. Have you checked if the port allocation requests for DCCP in
Section 6, seem right?
Yes, they look fine. Although I would not use Perf, the vast vast vast
majority of port allocations are all lower case.
Eddie
Oded,
I think I agree with your analysis, and believe that you have found an error
in the RFC.
There are two problems, the problem of shutting down the half-open connection,
and the problem of TIMEWAIT state. It is easier to solve the first problem.
(A) Partial solution: A half-open
The document's basic outline seems fine. Using a new packet type for this
purpose seems fine. The document is not ready to publish yet, because of a
high typo load and lack of specificity in how packets are processed (i.e. no
explicit pseudocode changes). These problems can probably be
Fernando Gont wrote:
Hello, folks,
I'm trying to finish a rev of the port-randomization I-D. The only
remaining bit is the DCCP-specific text. It'd be great if any you could
help me with closing these remaining bits...
Comments in-line...
So the question in this regard wrt DCCP would be: if
Hi Lars,
I vote for (1), SCTP-specific and DCCP-specific UDP encaps.
Although those specific encaps could be very similar, or in fact
identical at first, there are enough protocol differences to recommend
planning ahead for potential divergence.
At minimum there could be two documents that
Hello all,
I understand that WGLC for this draft has concluded, but in case comments are
useful, here are several. I strongly approve of the document; it is a clean
and useful spec and a good advance on prior versions, whether or not these
comments are addressed. The only technical comment
This isn't what you're asking, Gerrit, since you are (correctly)
worrying about UNEXPECTED differences that would only crop up in a
prototype, but here is a list of expected changes a kernel DCCP would
require to work with UDP encapsulation.
- Using a 6-tuple instead of a 4-tuple for flow
Using a 6-tuple for flow identification needs to be added to this list;
the spec is incorrect without it.
I have no objection to Gorry's firewall suggestion.
E
On 10/13/10 4:30 AM, Pasi Sarolahti wrote:
Hi,
To my understanding the status of the main issues and comments made on
I think you misunderstand.
Gerrit asked if *an existing kernel DCCP* would need to change to work with
UDP encapsulation. That's the question I answered.
DCCP-UDP encapsulation could be implemented at userlevel over a UDP socket
with no kernel changes. Some of its choices, such as the
Hi,
Will look over the new draft, but I have a response to your comments. It
would be good to hash it out.
On 10/18/2010 04:19 AM, Gerrit Renker wrote:
* S3.3 When the Send RTT Estimate FEATURE [sic, note added word] is disabled,
the sender MUST NOT send RTT Estimate options Why
in RFC4340/4342/5622.
Eddie
Gorry
On 19/10/2010 01:38, Eddie Kohler wrote:
Hi,
Will look over the new draft, but I have a response to your comments. It
would be good to hash it out.
On 10/18/2010 04:19 AM, Gerrit Renker wrote:
* S3.3 When the Send RTT Estimate FEATURE [sic, note added word
Gerrit...
On 10/19/2010 10:42 PM, Gerrit Renker wrote:
It is justified by applying the suggestions made in that section. If you can
officially add what you have written in the preceding email as an erratum to
RFC 4340 we would be happy to use it. Otherwise we will not change it.
You and Gorry
S3.2.1 says:
A value of 0 indicates the absence of a valid RTT sample. The sender
MUST set the value to 0 if it does not yet have an RTT estimate.
I would also say A packet without an RTT Estimate option is considered to
carry an RTT Estimate value of zero.
S3.3 says:
When the
Hi Gerrit,
Hooray! I think we actually agree. Nevertheless, here is a full response.
On 10/28/10 4:01 AM, Gerrit Renker wrote:
When deciding to use the option without negotiation, something similar to
feature
negotiation needs to be defined, e.g. to require that Sender RTT estimate
options
Gerrit:
As I have explained now several times, all analogous features in DCCP are
defined with MUST/MAY language. You continue to use language like bypassing
feature negotiation that is simply not a correct description of the spec.
Feature negotiation is not being bypassed, as I hope you
specified in RFC4340/4342/5622.
If we can leave out the MUST NOT part, then less is more. Would that
be ok?
Gerrit
Quoting Eddie Kohler:
Gerrit:
As I have explained now several times, all analogous features in DCCP are
defined with MUST/MAY language. You continue to use language like
Hi Gorry,
The text is close; I've put a revision below. I have other comments on
that section too; also below. As for the 6-tuple, WG FEEDBACK would be
good.
1) Does the text capture the problem?
Reasonably well, could be better. 6-tuples are MUST, not SHOULD.
2) Do you think this is
Hi all,
Abstract: upward and downward compatible = normally written forward
and backward
Introduction: Doubt phrase Standards Track would survive WGLC.
1st sentence: move references to what they refer to.
This document defines a Standards Track update to both a sender and
receiver
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 for the DCCP ports as well. You can then use a
Colin,
The problem solved by the 6-tuple is that the receiver CANNOT simply throw
away the UDP ports. The UDP ports are a critical component of flow
demultiplexing. Do I misunderstand you?
Eddie
On 2/7/11 3:54 AM, Colin Perkins wrote:
On 1 Feb 2011, at 09:02, Pasi Sarolahti wrote:
On
, 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 simply throw away
the UDP ports. The UDP ports are a critical component of flow demultiplexing.
Do I misunderstand you?
Yes, you misunderstand.
Obviously
I think underspecified choices like this have been controversial with our
implementers in the past.
E
On 02/07/2011 04:16 AM, Gerrit Renker wrote:
| I have now implemented all the corrections in the UDP encaps draft,
| except for the issue of how we implement transport demultiplexing,
|
I like 4-tuple IP/UDP.
- Look up IP+UDP 4-tuple
- If flow exists and DCCP ports conflict, send Reset; otherwise continue
This seems no more complex than a straight-up 6-tuple.
The draft could introduce a new Reset Reason for encapsulated port reuse so
a tunneled endpoint could immediately
Dear Gerrit,
These changes are good ones and I think have made the document much cleaner
and better, thank you!
I have one comment on this draft, it is editorial:
DCCP B sends a Mandatory Change R(Send RTT Estimate, 1) to ask DCCP
A to send RTT Estimate options as part of its data
Hi Gorry, looks good! Only nits:
On 2/10/11 1:58 AM, Gorry Fairhurst wrote:
A DCCP-UDP endpoint MAY use any UDP port number, providing the active
endpoint knows a valid UDP Destination Port on the passive endpoint.
By default, a DCCP-UDP client sets the destination port
to the default port
The draft looks good!
(There's one nit -- in S4 Encapsulations should be Encapsulation -- but
good.)
Eddie
On 2/25/11 2:56 AM, Pasi Sarolahti wrote:
Hi,
This mail starts a working group last call for the UDP encapsulation draft. The
draft is available at
Hi Gerrit,
Lars is right, cannot is far more idiomatic, in written or spoken text.
http://www.drgrammar.org/frequently-asked-questions#30
http://www.wsu.edu/~brians/errors/cannot.html
Eddie
On 3/4/11 3:54 AM, Gerrit Renker wrote:
Lars, -
| than 4 can not be determined: such samples
in technical writing.
-Original Message-
From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On
Behalf Of Eddie Kohler
Sent: 04 March 2011 15:27
To: Gerrit Renker
Cc: dccp@ietf.org group
Subject: Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
Hi Gerrit,
Lars is right, cannot
Well, TFRC is only one of DCCP WG's four chartered areas.
DCCP implementation and deployment experience seems to show that rate-based
protocols are simply harder to implement than ack-paced protocols. There are
a lot of good implementation reasons for this. As a result, TFRC isn't a
67 matches
Mail list logo
