[17:09:51] --- jishac has joined
[17:14:26] --- brabson has joined
[17:19:29] --- sarolaht has joined
[17:20:03] --- sarolaht has left: Logged out
[17:21:02] --- mallman has joined
[17:21:46] <jishac> So the agenda is at http://www.ietf.org/ietf/04aug/dccp.txt
[17:21:56] --- sarolaht has joined
[17:24:47] --- xmlscott has joined
[17:26:19] <jishac> Slides for today's event provided at:
[17:26:21] <jishac> http://www.icir.org/kohler/dccp/ietf60/
[17:26:28] <jishac> Agenda Bashing
[17:27:10] <jishac> WGLC: Spec, CCID2, CCID3
[17:27:32] <jishac> All for Prop. STD, scheduled to conclude on 8/20/04
[17:27:59] <jishac> Milestones:
[17:28:25] --- xmlscott has left
[17:29:01] <jishac> Most were missed so they were pushed up slightly past this current IETF
[17:29:12] --- Jukka Manner has joined
[17:30:00] <jishac> CCID 3 and Real-time interactive has been active on the list
[17:31:05] <jishac> proposals for improving performance, needs measurements for backup to the claims, and applicability guidance belongs in the user guide
[17:32:00] --- sakai has joined
[17:32:02] <jishac> Eddie Kohler : Presenting : DCCP Spec
[17:32:20] <jishac> Removed Mobility and Mulihoming
[17:32:31] <jishac> Extended sequence #s
[17:32:39] <jishac> Feature negotiation
[17:32:41] <jishac> Other changes
[17:33:17] <jishac> Extended SN's.... 24 and 48 were in the original and nogotiated
[17:33:38] <jishac> 48 bit # were advantages for several reasons
[17:34:00] <jishac> could go from 24 -> 48 durring a connection but not back to 24
[17:34:34] <jishac> The SN is the main defence against blind attacks (corresponding to the tcpsecure issues)
[17:36:37] <jishac> Change made so that there is no more transition between sizes and the default it 48 bits long, with the option for *only* DATA, DATAACK, and ACK packets to have 24 bit SN's
[17:37:00] <jishac> code on sequense numbers
[17:37:33] <jishac> Mark Allman: 32 bits used to be ok for tcp too
[17:38:45] <jishac> EK: they mean slightly different things, you loose about 10 bits for DCCP b/c of the differences (like bytes vs packets)
[17:39:19] <jishac> MA: (brings up the notion that chalenge responses could be used as well)
[17:40:06] --- Wag has joined
[17:40:16] <jishac> EK: Notes that, mentions that there is a posiblity that a timestamp solution could possbily be introduce in the future and that you couldn't really chalenge/response each packet
[17:41:29] <jishac> [ Missed next though, something about data integrety -joe ]
[17:42:32] <jishac> Mark Handley: This is a simple mechanism and as best a comprimise we can find in this space.
[17:43:10] <jishac> [ed addition] Soooo, I believe the issue was with 24 bit SN for DATA, and the potential for blind data injection....
[17:44:13] <jishac> and Mark was making a point that for applications such as A/V that some data injection would not be that big a deal, and if the app does care that much they could use 48 bit SN
[17:44:32] <jishac> A Mankin: Concured with Mark Handley.
[17:45:01] <jishac> Feature Negotiation:
[17:45:43] --- falk has joined
[17:46:20] <jishac> Updated reordering protection, enpoints can change pref list in the middle of a negotiation, and new Unstable state guarantees agreement anyways
[17:47:03] <jishac> *Other changes
[17:47:08] <jishac> - Rearanged header
[17:47:39] <jishac> - Ack # on DCCP-Sync does not indicate Acknowledgement
[17:47:59] <jishac> - DCCP-Reset codes in more detail
[17:48:26] <jishac> - Options to resets which can lead to a reset
[17:50:14] <jishac> Aaron Faulk: Why not move the X bit to the ____ (Missed it)
[17:50:39] <jishac> EK: Not sure it would work.... wanted to keep type a nibble but who cares about nibbles
[17:50:47] <jishac> AF: Examples of option for a reset?
[17:51:56] <jishac> EK: [I did *not* follow Eddie's response there were too many paths in the explination ]
[17:52:24] <jishac> But aparently Aaron did so he can insert them into the notes....
[17:53:35] <falk> eddie: add options to resets such that new dccps which understand the options may choose not to reset
[17:55:36] <jishac> Question arises to remove the text to remove the option to reset congestion state ( in case the path changes )
[17:56:07] <jishac> psudo-consensus to move it out of the spec and into a seperate document
[17:56:23] <jishac> ** Sally Floyd presenting
[17:56:49] <jishac> http://www.icir.org/kohler/dccp/ietf60/sally-ietf60-ccids.pdf
[17:58:26] --- sakai has left: Replaced by new connection
[18:03:30] <jishac> Discusses changes to CCID2 and CCID3
[18:03:43] <jishac> From last slide:
[18:04:09] <jishac> - Reinvigureate QuickStart, an expired ID?
[18:05:02] <jishac> - Introduce a new CCID for VoIP based on RFC 3714
[18:05:29] --- brabson has left
[18:06:22] <jishac> At some point, TFRC-PS, a variant of TFRC for flows that adapt their packet size.
[18:07:20] <jishac> EK Presenting about a draft 2 mtgs ago, CCID3-light
[18:07:27] <jishac> Slides at http://www.icir.org/kohler/dccp/ietf60/eddie-ietf60-lite.pdf
[18:07:46] <jishac> Where to go from here?
[18:08:01] <jishac> Update based on main spec (ex require 48 bits)
[18:08:33] <jishac> Some pieces missing... Loss Interval option, need to enable ECN capability
[18:08:50] <jishac> Question is to keep it going, or to put it off untill there is aneed for it
[18:08:57] <jishac> AF: so anyone?
[18:09:31] <jishac> (Otherwise its in the trash)
[18:09:46] <jishac> Mic: hold on this until CC issues settle down a bit
[18:10:17] <jishac> /hold on/hold off on/
[18:11:17] --- gjthomas has joined
[18:11:51] <jishac> Mic collaboration: Suggestion on doing a lightweight version on something that would end up eventually as a RFC, or maybe just a document on how to make it simpler
[18:12:12] --- gjthomas has left
[18:13:42] <jishac> EK: So this document is a simplification of both DCCP and the CCID
[18:15:32] <jishac> MH: Thinks it's a usefull informational draft
[18:15:54] <jishac> EK: It would take a bit of modification b/c the draft alocates and option.
[18:16:05] --- Wag has left: Disconnected
[18:16:15] <jishac> AF: Does the draft violate any MUST's in the spec
[18:16:18] <jishac> EK: no
[18:18:19] <jishac> EK: Explains, so if you have a thin and a full receiver, then the full receiver needs to understand thin, otherwise the full server could generate segments that the thin client will not understand and thus reset the connection.
[18:18:54] <jishac> AF: (Looking for feedback)
[18:19:13] <jishac> [ I couldn't here Alison's question -jishac ]
[18:21:59] <jishac> AM (at the mic): sounds like your creating an extention to the negotion mechanism and that's why your asking for it now than later
[18:22:51] <jishac> EK: not really, believes this can go to PS without this that this can be added on later ( b/c of the manditory option )
[18:24:06] <jishac> Mic: wants to clarify if this is a collection of minimum options
[18:25:07] <jishac> So this is not as complex as a full DCCP that just rejects every non esential option.
[18:25:20] <jishac> Humm on whether to consider this:
[18:26:03] <jishac> Split decission by only a handfull of people (10 or less), majority humm in the don't care choice.
[18:26:33] <jishac> AF: (descides to take it offline for said smaller group)
[18:27:04] <jishac> ** EK presenting on Mobility and Mulithoming
[18:27:12] <jishac> http://www.icir.org/kohler/dccp/ietf60/eddie-ietf60-mobility.pdf
[18:32:51] <jishac> Questions for the WG:
[18:33:03] <jishac> * Is mobility and multihoming worthwhile? * Should we continue with this draft? * Is another approach preferred?
[18:33:44] <jishac> Mic: Can this just be handled at a lower layer?
[18:34:26] <jishac> EK: Does believe that there is a stong case for suporting mobility at the transport layer instead of the network layer
[18:34:56] <jishac> AF: Dicission may be drived by activity in other working groups
[18:35:15] <jishac> May need to take a wait and see aproach
[18:36:08] <jishac> MH: Would like to keep going forward with this, don't want to stop, but don't want to make a decission without seeing what goes on in other working groups.
[18:36:28] <jishac> AF: Looking for hands on who may want to contribute...
[18:36:46] <jishac> See 1, 2, 3 hands.... basically, non-zero
[18:38:16] <jishac> AM: Likes what's in the document, thinks it contains a lot of neet things that are important to the architecture, and information that should be pulled by others.
[18:39:55] <jishac> Tom is next
[18:40:39] <jishac> http://www.icir.org/kohler/dccp/ietf60/tom-ietf60-userguide.ppt
[18:40:55] <jishac> Changes to the userguide from -01
[18:41:15] <jishac> no substantive changes
[18:41:22] <jishac> tired to improve tone
[18:41:46] <jishac> API doc not acted on
[18:41:55] <jishac> Soooo, what's next?
[18:42:06] <jishac> AF: Show of hands of who's read the draft....
[18:42:46] <jishac> Rather than flog people for not reading it (which he'd like to do), suggest pushing it to LC and then flog ppl for not reading it
[18:43:24] <jishac> Tom on MFRC
[18:43:26] <jishac> http://www.icir.org/kohler/dccp/ietf60/tom-ietf60-mfrc.ppt
[18:46:16] --- BP has joined
[18:50:24] <mallman> boy
[18:50:29] <mallman> why is this in the ietf?
[18:52:47] <jishac> EK: What the drafts intends to inform people that people who implement DCCP will have CC and that there will be no CCID 99 that has no CC
[18:53:20] <jishac> MA: Inturupted by AF: TCPM?
[18:53:36] <jishac> MA and Ted: Absolutely not :)
[18:54:02] <jishac> MA: is this ready?
[18:54:17] <jishac> SF: Concures, that this is the right place, may not be ready
[18:54:27] --- mallman has left: Disconnected
[18:54:59] <jishac> Mic: (Use ECN?)
[18:55:01] --- mallman has joined
[18:57:33] <jishac> AF: So if there is a CCID to be developed this would be the right place, but we need to figure out what needs to be done. Anyone interested in colaborating?
[18:57:39] <jishac> (Show of hands)
[18:59:32] <jishac> Last part of the agenda, open discussion.
[18:59:40] <jishac> open issues
[19:00:08] <jishac> AF: is there a lack of a needed CCID?
[19:00:15] <jishac> AF: other issues
[19:01:12] <jishac> Magmus: Question is it mature enough to go to Proposed without and implementation
[19:01:54] <jishac> AF: quick answer is yes, b/c the featuers have been talked about for 2 yrs and have been hashed over quite a bit and an implementation is not required for PS
[19:04:13] <jishac> Steve Castner: Several things that are not quite certian, so it doesn't seem ready (didn't specify the issues he had heartburn with)
[19:04:32] <jishac> Mic: Q on how well this will apply to a wireless link
[19:04:59] <jishac> Will DCCP behave better than TCP in the radio environment
[19:07:46] <jishac> MH: A decent DCCP implementation will be able to handle the delay
[19:09:21] <jishac> Colin Perkins: not woried about the applicability, can develope more CCID's as needed
[19:09:47] <jishac> Woried about pushing something forward that not ready, had 9 pgs of changes for this mtg
[19:09:57] <jishac> not convinced it's stable
[19:11:05] <jishac> SF: if ppl are going to hold this back b/c it's not stable then it's silly b/c TCP isn't stable
[19:11:38] <jishac> can't have no issues, make sure there is no evolution that will still happen etc... can't happen
[19:11:54] <jishac> /no issues/ zero issues/
[19:12:12] <jishac> [ double negatives ... yeah yeah.... ]
[19:15:20] <jishac> AF: PPL read the draft
[19:18:18] <jishac> Randall Stewart: On Sally's team, the only way to find mistakes, get comments, etc.... is to actually get to PS and get a dozen implementations to bash on.
[19:18:41] <jishac> AM: Either LC or make a quick rev
[19:19:50] <jishac> thinks this is an appropriate action sometime documents in LC get changed quite a bit, supposed to react to discussion....
[19:20:17] <jishac> So alison's feal is that it's high time for last call
[19:20:53] <jishac> MA: want's to very quickly agree with sally, it's never going to be perfect and its time to get a stable version out to get people marching
[19:20:56] --- Jukka Manner has left
[19:21:02] --- BP has left
[19:21:03] <jishac> That was the final word
[19:21:11] <jishac> final orders by aaron
[19:21:16] <jishac> READ UP
[19:21:20] <jishac> :)
[19:21:27] <jishac> EOF
[19:21:29] --- Jukka Manner has joined
[19:22:29] --- Jukka Manner has left
[19:22:45] --- sarolaht has left
[19:23:25] --- jishac has left
[19:27:21] --- falk has left: Disconnected
[19:28:01] --- mallman has left: Disconnected