headers
Bob Briscoe | 1 Aug 2007 04:02
Picon

Re: Initial I-D: draft-briscoe-tsvwg-byte-pkt-mark-00

Sally,

Again, catching up on my backlog - apologies for delayed reply...

At 00:30 20/07/2007, Sally Floyd wrote:
>Bob -
>
>Some feedback on "Byte and Packet Congestion Notification",
>draft-briscoe-tsvwg-byte-pkt-mark-00:
>
>It seems odd to me to talk about RED in byte vs. packet mode, and
>not to talk about the similar performance difference between
>Drop-Tail queues in bytes vs. packets.  (Well, someone could
>care about RED and not Drop-Tail because one cared only
>about packet marks in an ECN environment, but for this document
>it strikes me as quite odd to talk about RED in byte vs. packet mode,
>and not to talk also about Drop-Tail queues in bytes vs. packets.)
>
>I am enclosing some text from some 2/26/2007 email that I sent you
>about this, in response to "draft-briscoe-tsvwg-byte-pkt-mark-00c".
>(I didn't reread the new draft, but I did look at the diffs between
>draft-briscoe-tsvwg-byte-pkt-mark-00 and
>draft-briscoe-tsvwg-byte-pkt-mark-00c, and I didn't notice anything
>added about Drop-Tail queues in bytes vs. packets.)

After I had posted the draft, I realised I still hadn't taken this point 
you made into account. Sorry about that - it will be in the -01 update.

I tried to make up for this at least in my presentation in Chicago, where I 
warned people not to turn off RED altogether (actually, I hadn't read this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sally Floyd | 1 Aug 2007 04:19
Picon

Re: draft-kohler-dccp-ccid3-drops-01.txt Re: Remote participation in DCCP WG, IETF-69

Ian -

Many thanks for the feedback.

>> I have a couple of comments I'd like raised if possible (not sure I'll
>> be attending via jabber):
>> - is this actually needed as a separate RFC? Given how small it is,
>> perhaps it is more of a start of CCID3bis? I don't really know
>> anything about IETF processes though - so it may be appropriate as it
>> is - it just seems it would be better in core CCID3 document.

Whenever CCID3bis is started, this would certainly become part
of it.  But for now, I think this is appropriate for a separate RFC,
that will get incorporated into the core CCID3 document whenever
CCID3bis is undertaken.  (As an example, it would be a drag
if whenever one wanted to add new functionality to TCP congestion
control, one had to start a new bis of a single document that
encompassed all of TCP congestion control (e.g., initial windows,
timers, highspeed TCP, SACK options, responding to dup acks, etc...)

>> - Given that it is a standalone document I think it could be clarified
>> a little. In Section 3.1 it discusses how the content should basically
>> match loss intervals, which does make sense. I think it should make
>> explicit reference to section 8.6.1 of RFC4342 though. In particular
>> it should discuss how many loss counts to send.

That sounds ok to me.  Section 3.1 says the following:

     "Dropped Packets options SHOULD be sent in tandem with corresponding
     Loss Intervals options...  When this receiver sends a feedback
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 2 Aug 2007 16:09
Picon
Picon

Re: Comments on DTLS/DCCP I-D

Phelan, Tom wrote:

> Hi Gorry,
> 
> [clipped]
> 
>>8) Do you propose to document some Service Code values for
> 
> IETF-defined
> 
>>services, e.g. Define some SC allocations for  RTP/DTLS/DCCP?
> 
> 
> I don't see any "generic" applications that should be defined (if RTP
> wants to use DTLS, then I think whoever wants to do it should define
> it).  
OK. I guess the first person with a DTLS stack over DCCP should do this, 
though before they use a SC that's not assigned.

> Given DTLS' need for authentication, usually via a certificate on
> at least one side, I don't think we should define the generic services
> in your SC draft as also operating over DTLS.
> 
Fine. People shouldn't start using unassigned SC in their apps!

> I'm open to counterarguments, though :-).
> 
> Tom P.
> 
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gorry Fairhurst | 2 Aug 2007 16:11
Picon
Picon

Re: Comments on DTLS/DCCP I-D

ACK, for applications that do not need a new PORT for a new protocol 
version, they should not need a new SC.

I am now accumulating enough material for a new rev -01 of the SC draft, 
which is great.

Gorry

Phelan, Tom wrote:

> Hi Gorry,
> 
> I'm incorporating your comments into DTLS over DCCP, and I think the
> comment involving the effect of new DTLS versions on Service Codes is
> more general than just DTLS and probably will deserve some text in the
> SC draft.
> 
> So I've added the following to the DTLS draft:
> 
> It is RECOMMENDED that an application migrating to a new version of DTLS
> keep the same DCCP Service Code used for the old version and allow DTLS
> to provide the version negotiation support.  If the application
> developers feel that the new version of DTLS provides significant new
> capabilities to the application that will change the behavior of
> middleboxes, they MAY use a new Service Code.
> 
> I suggest you add something similar to the SC draft, e.g.:
> 
> It is RECOMMENDED that a new version of an application keep the same
> DCCP Service Code used for the old version and provide version
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phelan, Tom | 2 Aug 2007 16:31
Favicon

RE: Comments on DTLS/DCCP I-D

Hi Gorry,

[clipped]
> > I don't see any "generic" applications that should be defined (if
RTP
> > wants to use DTLS, then I think whoever wants to do it should define
> > it).
> OK. I guess the first person with a DTLS stack over DCCP should do
this,
> though before they use a SC that's not assigned.

[Tom P.] Well, the first person that writes an application that uses
that DTLS stack, actually -- the SC isn't for DTLS, it's for an app that
uses DTLS.

Tom P.
Permalink | Reply | 0 comments |
headers
Phelan, Tom | 2 Aug 2007 16:40
Favicon

New DTLS over DCCP draft

Hi All,

I've sent a new version of DTLS over DCCP (-01) to Internet-Drafts.
While we're waiting for it to percolate through, it's available at
http://www.phelan-4.com/dccp/draft-ietf-dccp-dtls-01.txt.  A version
with diffs from -00 is also available at
http://www.phelan-4.com/dccp/draft-ietf-dccp-dtls-01-diffs.pdf.

Tom P.
Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 2 Aug 2007 22:14
Picon
Picon

Comments on CCID-4: draft-floyd-dccp-ccid4-01.txt


While preparing for the IETF meeting, I re-read CCID-4 and have some
comments on the current revision, which I would like the authors to
consider.

Best wishes,

Gorry

Comments:

----
Page 8 first para.
Is it sufficient to assume the header size is 36 bytes, given the large
space that could in future be allocated to DCCP options?
- I think the text should mention options processing.
- There are also options in IPv4 (and IPsec), and the important case of
IPv6 which may need to be mentioned.
- My suggestion is that at least these issues should be highlighted, and
an IPv6 case given explicity.
----
Is the CCID-3 Loss Intervals option defined for other CCIDs beyond 3?
- A quick look at the Registry suggests that some options that are
desirable for CCID-4, were defined only in CCID-3 specific registries.
- Most of the IANA considerations also applies to this new CCID.
- Do you wish to redefine these here also for CCID-4?
----

Editorial work:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sally Floyd | 2 Aug 2007 23:53
Picon

second pass on notes from the DCCP meeting last week

DCCP Working Group Meeting, July 23, 2007.
Notes from Sally Floyd and Tom Phelan.

Agenda Bashing

Document Status - Gorry.
* To-Do Milestones.
[See presentation.]
"We are looking for someone to contribute to a user guide."
Lars wants someone to write a document on middlebox considerations
  for DCCP, in the BEHAVE working group.  This would be about how
  NATs should munge DCCP packets that traverse them, mirroring other
  BEHAVE documents about UDP or SCTP.  The DCCP-specific issue
  will be about service codes.

TFRCbis - Sally Floyd
Version 2 of draft
TFRCbis has larger initial sending rates that TFRC, reflecting changes in TCP.
Three main changes from -01:
* Mechanism for resonding to the feedback packet after an idle period.
* Response to idle and data-limited periods.
* Use of unused send credits.
[and so on from presentation.]
Mark Handley: For the last bullet on the last slide about related work,
  what will the app writer do about data limited periods, given
  what is suggested in the last bullet for TFRCbis?  Should the app
  pad the flow so that it will get what it needs when it needs it?
  That's what I expect they'll do.  We should think about people's
  incentive to pad their sending rate during idle periods.
Sally:  By the same argument, apps would pad TCP data too.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sally Floyd | 3 Aug 2007 06:12
Picon

Re: Comments on CCID-4: draft-floyd-dccp-ccid4-01.txt

Gorry -

> While preparing for the IETF meeting, I re-read CCID-4 and have some
> comments on the current revision, which I would like the authors to
> consider.

Many thanks.
I will try to get to this in the next week.

- Sally
http://www.icir.org/floyd/
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 6 Aug 2007 23:15
Picon
Favicon

I-D ACTION:draft-ietf-dccp-dtls-01.txt

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		: Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)
	Author(s)	: T. Phelan
	Filename	: draft-ietf-dccp-dtls-01.txt
	Pages		: 7
	Date		: 2007-8-6
	
This document specifies the use of Datagram Transport Layer Security
   (DTLS) over the Datagram Congestion Control Protocol (DCCP).  DTLS
   provides communications privacy for datagram protocols and allows
   client/server applications to communicate in a way that is designed
   to prevent eavesdropping, tampering, or message forgery.  DCCP is a
   transport protocol that provides a congestion-controlled unreliable
   datagram service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dccp-dtls-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
(Continue reading)

Permalink | Reply | 0 comments |

Gmane