[01:54:55] --- Dado has joined
[04:09:47] --- Dado has left
[07:05:17] --- falk has joined
[07:07:03] <falk> SLIDES FOR DCCP IETF-61 ARE AT http://www.isi.edu/~falk/dccp
[07:34:46] --- Dado has joined
[07:37:17] --- Dado has left
[07:48:48] --- gorryf has joined
[07:49:51] --- Dado has joined
[07:50:36] --- mallman has joined
[07:56:00] <falk> can you hear/see?
[07:56:16] <falk> sorry. Can anyone on multicast hear and/or see?
[07:57:11] <mallman> i am on the unicast audio stream and i can hear you
[07:57:24] --- csp has joined
[07:57:39] <gorryf> Gorry Fairhurst: Jabber Scribe for DCCP WG IETF-61
[07:57:41] <gorryf> (others please do add comments too)
[07:58:43] --- yjs has joined
[08:00:56] --- Jukka Manner has joined
[08:00:59] --- admcd has joined
[08:01:06] <Jukka Manner> morning dado
[08:01:52] --- csp has left
[08:01:59] --- sureshk has joined
[08:02:05] --- sureshk has left
[08:02:26] --- Suresh Krishnan has joined
[08:03:13] <gorryf> (Aaron is now debugging the laptop to projector screen connection)
[08:04:24] <mallman> someone tell aaron that there is a permission problem with eddie's slides on his web page.
[08:04:31] <gorryf> (Eddie is comming to the rescue - but his doesn't work either - maybe it was not a mac problem?)
[08:05:29] <mallman> eddie's slides only
[08:05:57] <mallman> thanks gorry
[08:06:12] <gorryf> I told Eddie and Aaron
[08:06:43] <gorryf> Screen now working and about to start (FYI: it was a cable problem, not a computer one)
[08:06:44] <mallman> got the slides!
[08:08:35] <gorryf> Agenda Bashing - Aaron Falk
[08:09:19] <gorryf> TFRC research will be reviewed and results; then Work Items; perhaps finish early.
[08:09:49] <gorryf> WGLC complete on Spec, CCID2, CCID3 - some small changes
[08:10:38] <gorryf> Milestones to be updated on web page.
[08:10:56] <gorryf> User guide was in limbo.
[08:11:32] <gorryf> Need to look at the next work that needs to be done - Charter update was all sent to the list.
[08:11:43] <gorryf> VoIP:
[08:11:45] --- jishac has joined
[08:12:10] <gorryf> Sally will say more on this later.
[08:13:23] <gorryf> Any comments on this? (or say later?)
[08:13:30] <gorryf> No comments at moment.
[08:13:38] <gorryf> Possible new owrk items:
[08:14:14] <gorryf> Where should TFRC be discussed?
[08:14:17] --- admcd has left
[08:14:29] <gorryf> AM: Let's do process discussions for 6 months :-)
[08:14:55] <mallman> yeah... mic is nice
[08:15:31] --- admcd has joined
[08:15:47] <gorryf> Eddie: Is CCID-Thin a possible work item?
[08:16:09] <gorryf> Aaron: Tom at the last IETF said it was mainly a thought process...
[08:16:23] <gorryf> Tom: CCID-Thin was mainly pointing to voice implementation
[08:16:35] <gorryf> This was delayed, rather than cancelled
[08:16:49] <gorryf> Aaron: more work is possible?
[08:17:01] <gorryf> This could be an addition to CCID2.
[08:17:13] <gorryf> --- DCCP Spec (draft-ietf-dccp-spec-08.txt) - Eddie Kohler ---
[08:17:31] <mallman> the powerpoint cable... please
[08:18:00] <mallman> YEAH. HELLO.
[08:18:15] <gorryf> Revenge of the DCCP Spec
[08:18:24] <mallman> tell eddie to talk into the mic
[08:18:36] <gorryf> Is he talking now at the right level?
[08:19:00] <mallman> yeah, better
[08:19:10] <mallman> he keeps turning his head, i bet
[08:19:25] <gorryf> OK - he's walking around the room :-)
[08:19:36] <gorryf> Header Rearrangement:
[08:19:55] <mallman> yeah. i sympathize because i do the same thing when talking.
[08:20:06] <gorryf> Header Analysis: Not clear of gain ...
[08:20:54] <gorryf> Assume most DCCP Applications use data packets (rather than with ACK) - there is no gain, data packets are the same size.
[08:21:21] <gorryf> Agreement on current header design - but complexity cost for two types of sequence numbers (some not sure of this)
[08:21:41] <gorryf> Possible alternate header: move reserve bits to get options?
[08:21:54] <gorryf> Comments on this will be welcome.
[08:22:04] <gorryf> Feature Negociation:
[08:22:40] <gorryf> * Congestion Control:
[08:23:39] <gorryf> CCID was controversial - a hole through which one could drive a truck?
[08:23:58] <gorryf> This would not work for any existing CCID - CCID 1 now removed.
[08:25:16] <gorryf> Perkins suggested ECN (with NONCE) should be mandatory... Eddie Agree... Sally did not (reserved bits can be dangerous) - Editorial features to make ECN default
[08:25:57] <gorryf> Removed reset congestion state option
[08:26:37] <gorryf> Data drop is mentioned has to be reliable (until sender got option)
[08:27:04] <gorryf> Aaron: how many people have read the spec?
[08:27:07] <gorryf> 10-15
[08:27:12] <gorryf> How many have sent comments?
[08:27:20] <gorryf> 5 (ish)
[08:27:29] <gorryf> * Packet exchange:
[08:28:18] <gorryf> Can have zero length data packets (should these be reported to the app? - now a SHOULD)
[08:28:38] <gorryf> DCCP reset options *are* now processed.
[08:29:12] <gorryf> Consequences - a reset can be discarded because of an option problem, but bot cause a reset state change)
[08:29:47] <gorryf> * Ignoring options in DCCP data
[08:30:08] --- dinakar has joined
[08:30:19] <gorryf> We didn't worry about attacks using a DCCP-Data packet injecting data into a connection?
[08:30:48] <gorryf> Data injection attacks are not that useful to attackers (SB) because result is unclear.
[08:31:23] <gorryf> Problem is with options (mandatory feature) which could change state - this viable attack.
[08:32:22] <gorryf> Solution to explicitly mark options that do state change - and change rules.
[08:32:49] <mallman> mic
[08:33:02] <gorryf> Question: Tim: Did you include the reasoning?
[08:33:33] <gorryf> - Eddie he will do this?
[08:34:05] <gorryf> * Security:
[08:34:12] <mallman> i do not remember suggesting this ...
[08:34:18] <mallman> but, it sounds like a decent idea
[08:34:20] <mallman> :-)
[08:34:21] <falk> (Question was from Ted Faber)
[08:34:27] <gorryf> Ok :-
[08:34:29] <falk> Mark: you did suggest this
[08:34:43] <mallman> oh
[08:34:49] <gorryf> Rosen: More consideration of plain injection attack?
[08:34:55] <mallman> i believe you
[08:35:05] <gorryf> It's an attractive attack to some people (??)
[08:35:23] <mallman> i remember thinking that section could be beefed up. i just dont remember this notion of 50% success.
[08:35:24] <gorryf> A single packet insert is a bad thing to a media stream.
[08:36:01] <gorryf> Eddie: The spec says a fair bit - end can also refuse 24bit sequence number, and therefore increase robustness (with header size)
[08:36:58] <gorryf> Mark Handley: application writer is the only one who knows.
[08:36:59] <mallman> comment: but,will the app writer understand that tradeoff?
[08:37:23] <gorryf> Collin P: Application writer needs to know what to do...
[08:37:32] <gorryf> Trade-offs for data injection?
[08:37:37] <gorryf> Yes - Eddie
[08:37:55] <mallman> will the app writer read the dccp spec?
[08:38:01] <gorryf> Eddie to Mark's answer - yes I hope applications will do this.
[08:38:08] <mallman> mark is right
[08:38:16] <gorryf> Mark H: Spec is not the correct place to do this.
[08:38:51] <gorryf> * Miscellaneous:
[08:40:10] <gorryf> CRC computation; Timestamps now measured in 10 microsec ganuality; path MTU; IANA
[08:40:35] <gorryf> * Open Questions:
[08:40:58] <gorryf> - places were consensus was not reached - some that do not require change.
[08:42:09] --- admcd has left
[08:43:19] <mallman> who is talking at the mic?
[08:43:24] <falk> colin
[08:43:28] <gorryf> Collin P: Can we do init cookies?
[08:43:29] <mallman> thanks
[08:43:59] <gorryf> - eddie take the options from the first packet and encrypt etc, to make a cookies
[08:43:59] <falk> mark: anything to add?
[08:44:12] <gorryf> Collin P: Say what syn cookies are - and give a hint?
[08:44:16] <mallman> i think i have said my bit here. people will get it wrong.
[08:44:33] <gorryf> Eddie: that seems ok (woth no pseudo code)
[08:45:17] <gorryf> Multiple apps can be demux using service code
[08:45:52] <gorryf> - could confuse sysadmin (who think of a security property - one per port)
[08:45:56] <gorryf> Collin P: Yeas
[08:46:18] <gorryf> - The reason is TCP and UDP have one app per port (thsi can cause confusion)
[08:46:26] <gorryf> Allison Mankin :
[08:47:00] <gorryf> SCTP doesn't - different apps within associations - XML doesn't - this doesn't happen already.
[08:47:15] <gorryf> IF Steve B. thinks this is a good idea...
[08:47:41] <gorryf> Collin: Yes but - When I try to explain this there is confusion.
[08:48:00] <gorryf> Mark H: There is ambiguity on whether to block on ports or codes.
[08:48:06] <gorryf> Eddie : not all authors agree
[08:48:25] <gorryf> Collin P: Not a huge issue - but there is potential confusion.
[08:48:30] <gorryf> Eddie - we should keep this
[08:48:59] <gorryf> ?: having fought at cisco, this causes confusion to people who look at ports?
[08:49:00] <falk> Randall Stewart
[08:49:36] <gorryf> Eddie: Firewalls will use DCCP ports (that's why they are the way they are) service codes are for smarter firewalls in the future
[08:50:01] <gorryf> No Glossary - Eddie would nee help?
[08:50:30] <gorryf> - No glossary without WG inputs.
[08:51:37] <gorryf> Aggression penalty could be a hit with data injection - so this is a DoS vulnerability, also with ACK for packet never sent
[08:52:39] --- dinakar has left
[08:53:07] <gorryf> Questions?
[08:53:24] <gorryf> Aaron: IPsec SPD is specific to protocol, port?
[08:54:24] <gorryf> Can anyone carry this to the IPsec community (the SPD - uses protocol and port number) - is this a real issue?
[08:54:37] <gorryf> Collin: how does service codes effect this?
[08:54:45] <gorryf> Soudns like IPsec is agnostic
[08:55:22] <gorryf> Allison M; They almost never do anything with port numbers (but do need action on protocol numbers)
[08:55:37] <gorryf> - IPsec was supposed to be per port (application) - but not common.
[08:55:44] <gorryf> is this a spec change?
[08:56:09] <gorryf> AM: supposed to be able to extend this (UDP-Lite is in the same space).
[08:56:28] <gorryf> AM: SCTP had significant issues with multi-homing (so draft required)
[08:57:01] <gorryf> AM: A smaller draft is probably good (could cover both DCCP and UDP-Lite)
[08:57:16] <gorryf> Mark H: Flow association is based on port (not service code)
[08:57:33] <gorryf> Collin: can we run two apps on the same port?
[08:57:52] <gorryf> Eddie: same can happen in TCP (redirect) - same case.
[08:58:40] <gorryf> Aaron: you won't eb able to make service-code decisions.
[08:59:26] <gorryf> Collin P: If we use port-specific for firewalls and then service-codes for setup - isn't this strange?
[09:00:04] <gorryf> AM: We have more "knobs" for firewalls to use - we are not pushing anything different to the IPsec.
[09:01:01] <gorryf> Aaron: this is a none-issue. (there are no issues to IPsec or the use of service codes)
[09:01:02] <gorryf> ---- CCID2 (draft-ietf-dccp-ccid2-07.txt) - Sally Floyd ---
[09:01:10] <gorryf> WGLC comments
[09:01:11] <mallman> no
[09:01:20] <mallman> yes
[09:01:27] <falk> 1
[09:01:29] <falk> 0
[09:01:38] <gorryf> ???
[09:01:48] <mallman> answering about the mic
[09:02:02] <gorryf> Ah... back to the notes.
[09:02:09] <gorryf> * Status:
[09:02:44] <mallman> the min ssthresh moved from 1 to 2, not 2->1, as on sally's slides. right? (that was the suggestion anyway)
[09:02:58] <mallman> (coming later)
[09:02:59] <gorryf> ABC is a good thing (in next rev)
[09:03:08] <gorryf> * Ack ratio:
[09:03:36] <jishac> mallman: yeah, I think that's what it says in the draft
[09:03:41] <gorryf> Sender SHOULD not change ACK ratio more than once per PRTT.
[09:03:53] <gorryf> * Why at most RTT...?
[09:04:29] <jishac> from the draft's list of revisions: "* Specified that ssthresh is never less than two, instead of one."
[09:04:35] <gorryf> * Minimum for ssthresh?
[09:05:20] <gorryf> * CCID2 masquerading..:
[09:05:29] <gorryf> Any quatesions?
[09:05:37] <gorryf> - None.
[09:05:45] <gorryf> ---- CCID3 (draft-ietf-dccp-ccid3-07.txt) - Sally Floyd ---
[09:05:59] <gorryf> WGLC:
[09:06:32] <mallman> hi sally
[09:06:39] <mallman> no kid yet! :-)
[09:07:03] <gorryf> * CCID3 spec heard to read:
[09:07:15] <gorryf> Current is obtuse.
[09:07:21] <gorryf> (I thought so too)
[09:07:41] <gorryf> * Why so many ways to convey loss?:
[09:09:10] <gorryf> 3 ways to convey loss (ACK Vectors - most important?; Loss Intervals - alternative with more receiver work; Loss Event Rate - with no ECN)
[09:09:44] <gorryf> Eddie question:
[09:09:48] <mallman> all of these things are certainly useful in theoretical constructs. but, what should really be done? it's a lot of complication. are people really going to think about all of these options?
[09:10:22] <gorryf> I agree all three - would it be simpler to require "loss intervals" in these cases?
[09:10:40] <gorryf> ^these^all^ - i.e. in all cases
[09:11:12] <gorryf> Eddie: reason to send ACK vectors is to tell which packets were lost?
[09:11:26] <gorryf> With ACK vectors you can change the way they are calculated.
[09:11:43] <mallman> who?
[09:11:44] <gorryf> Sally: It wouldn't bother me to make this mandatory
[09:12:01] <gorryf> - what was the comment ...
[09:12:12] <mallman> colin?
[09:12:14] <jishac> yes
[09:12:21] <gorryf> Collin P: ACK vectors should not be mandatory because they are big.
[09:12:42] <gorryf> Sally: yes - these should not be mandatory
[09:13:06] <gorryf> * Potential changes:
[09:13:59] <gorryf> Some issues listed as future changes (in appendix)
[09:14:12] <gorryf> * The loss intervals option:
[09:14:59] <gorryf> Loss intervals - 84 intervals (although TFRC uses latest 8), will change to 42 intervals (TFRC uses 9)
[09:15:23] <gorryf> * Clarifcations:
[09:15:59] <gorryf> * Questions?
[09:16:07] <gorryf> - EDdie:
[09:16:23] <gorryf> Aaron: Planning a revision for a new draft?
[09:16:36] <gorryf> - Will you remove future work ?
[09:16:41] <gorryf> sally: wahtever
[09:16:54] <gorryf> Eddie: more feedback on readability
[09:17:07] <gorryf> Sally: volunteered rewriting by Eddie ;-)
[09:17:54] <gorryf> ---- TFRC & VoIP simulation results - Tom Phelan ---
[09:19:34] --- Ted Faber has joined
[09:19:47] <gorryf> A paper and presentation are available (see first slide for URL)
[09:19:56] <gorryf> * Motivation:
[09:21:09] <gorryf> Self-limiting models G.711 VoIP 8 bits at 8 125 microsec.
[09:22:06] <gorryf> 64 kbps voice becomes about 96 kbps on the wire.
[09:22:54] <gorryf> * Simulation:
[09:23:37] <gorryf> * Simulation 3:
[09:24:34] <gorryf> bottom plot is the TFRC trace and this ramps down when TCP start to 20kbps (broken codec)
[09:24:50] <gorryf> * Simulation 7:
[09:25:20] <gorryf> Conversation understandable with CNR - well within its fair share
[09:25:57] <gorryf> TFRC is packet-rate based (not byte) - TFRC plots *do* get a fair share in pps.
[09:26:13] <gorryf> Paper was updated now to reflect this.
[09:26:22] <gorryf> New version on the web site.
[09:26:28] <gorryf> * VoIP mode:
[09:27:00] <gorryf> Special dispensation to flows sending no more than 100 pps. Lots more work, but early results promising
[09:27:06] <gorryf> * VoIP simulation:
[09:27:34] --- csp has joined
[09:27:54] <gorryf> Don't really know where the peakiness in TCP is?
[09:28:16] <gorryf> aaron: rate variation is this buffered out by the codec - is there underun?
[09:28:33] <gorryf> Tom: You don't know if there are actual effects from tehse plots.
[09:28:49] <gorryf> Jitter buffer would be 100ms typically.
[09:29:14] <gorryf> Sally: I would assume the defaults in TCP have been updated (to reflect reality)
[09:29:33] <gorryf> - So the buffering is likely causing TFRC burstiness?
[09:29:40] <gorryf> Steve Casner:
[09:30:08] <gorryf> I'd say you need to know the number that suffer excessive (late) codec loss.
[09:31:02] <gorryf> Mark H : The issue is that TFC is bursty - and this ius cuased by the link - then this is normal, buffering would help.
[09:31:22] <gorryf> Aaron: This is engineering...
[09:31:43] <gorryf> Sally: Could you (did you) add reverse path traffic?
[09:31:50] <gorryf> Tom: No we didn't.
[09:31:58] <gorryf> Eddie Thanks for data.
[09:32:23] <gorryf> (name)?: What has this to do with voice rather than streaming media?
[09:32:33] <gorryf> Noice uses small packets
[09:32:48] <gorryf> ? : streaming audio is this, video uses big packets.
[09:33:02] <gorryf> Aaron: Extend simulation to look like video?
[09:33:24] <gorryf> ?: Timing is different for audio..
[09:33:33] <gorryf> ?: And bi-directional.
[09:33:55] <gorryf> Eddie: High quality audio can give large packets.
[09:34:06] <gorryf> aaron: a difference between audio and voice (speech)
[09:34:19] <gorryf> Eddie: There are different cases.
[09:34:52] <gorryf> Collin P: This depends on buffering at the receiver - suitability for interactive apps is an issue, non interactive will work prettyu well.
[09:35:06] <gorryf> Tom: In the simulation, changing delays also changes things.
[09:36:18] <gorryf> S Weger (?): Video can result in very variable packet sizes... additional complexity to the problem (fill packets from a picture) when a picture goes into 2 or 3 packet and last packet is 1B and MTU
[09:36:32] <gorryf> There is more complexity (not yet considered)
[09:36:53] <gorryf> Tom P: here's a homework assignment to understand video streams.
[09:37:25] <gorryf> ?: If I need to keep 1% of packets late, etc there are trade-offs in the playout buffer.
[09:38:03] <gorryf> * DCCP User Guide:
[09:38:28] <gorryf> Aaron: Do people have opinions on the DCCP user guide constrcution?
[09:38:44] <gorryf> Eddie:
[09:39:20] <gorryf> Eddie: How long does it take VoIP mode to be written - we could wait for VoIP mode to be ready.
[09:39:24] <gorryf> Aaron: Why?
[09:40:01] <gorryf> Eddie: Because interactive applications are interesting (API issues apply across applications types)
[09:41:07] <gorryf> Aaron: How do we structure this: Streaming / Interactive - Voice / Video - Little contributions - the document is languishing. Why? - Advice needs to be given to users,
[09:41:48] <gorryf> Collin P: It would make sense to say how to use for cases were DCCP works. e.g. a non-interactive streaming application.
[09:42:34] --- admcd has joined
[09:42:36] <gorryf> ? : It does't work - there is no evidence that this works for anything - THE WHOLE THING IS BROKEN - no-one has made it work for anything, we know nothing.
[09:43:13] <gorryf> Eddie: kind-of agrees relating to the user guide - but this is not true of the spec - so the user guide needs work.
[09:43:47] <gorryf> Eddie: I don't think the document is languishing, this is the appropriate speed to evolve - it will evolve faster.
[09:44:01] <gorryf> Collin P: We need to talk about cases that do work.
[09:44:21] <gorryf> Tom: Should we stick to the strategy for the guide?
[09:45:10] <gorryf> Aaron: A summary is, I think we should document things we understand better (don;t worry about format or schedule for the user guide) as we udnerstand teh technical issues, we can focus.
[09:46:14] <gorryf> Collin P: keep updating the dates and content - There are easier case than VoIP which could be interested in TFRC.
[09:46:32] <gorryf> Brian: I want to see it work!
[09:46:51] <gorryf> (Brian was the man who spoke loudly 6-7 lines ago)
[09:47:37] <gorryf> aron: Implementation proof is not a requirement (we would like it). - revisions and changes may follow. WG will not stall on this.
[09:48:22] <gorryf> ?: There is stacks of code in BSD that could be used with audio/vdieo tools. It seems worthwhile to play with FreeBSD.
[09:48:56] <gorryf> Collin P: There are people trying to make mm tools congestion adaptive
[09:49:55] <gorryf> Allison M: Interactive voice is some way away from being at this point. IP video with CC is a big thing. There is big DCCP potential here.
[09:50:18] <gorryf> Collin P: There are a lot of people doing video over HTTP (which must be worse).
[09:50:42] <gorryf> Tom Phelan: I'd like to look at big buffers at the receiver.
[09:50:50] --- Suresh Krishnan has left
[09:51:17] <csp> [collin -> colin, btw]
[09:51:53] <gorryf> Mark H: DCCP is a "red herring" - the issue is congestion control (CC) - previous work includes use of VIC, etc, stored streaming media (pre-encoded), ethere are some solutions in this space - these are part of the MM issue not DCCP.
[09:52:05] <mallman> i think mark is right on
[09:52:19] <gorryf> Brian: the last project I did was interactive video - this would kill it.
[09:53:09] <gorryf> Brian: Spec - no problem, but don't know it is right for an application.
[09:53:47] <gorryf> Aaron: There is prior work on MM streams with CC - and this is a different problem.
[09:54:01] <gorryf> Brian: Not aware of succesful CC
[09:54:12] <gorryf> Tom Phelan: neither have I.
[09:54:38] <gorryf> Eddie: This is not the streaming media protocol - this is a Datagram transport.
[09:56:31] <gorryf> Collin: I listen to streaming radio over TCP - I think DCCP is better than this - It may not be good for (some) streaming apps.
[09:57:16] <gorryf> Sally: The CCIDs *are* better than TCP (no transmit timeouts), I agree with Collin for CCID2 (CCID3 is better), work is exploring new things.
[09:57:32] <gorryf> sally: People don't have to use the outputs of the WG
[09:58:32] <falk> speaker: magnus Westerlund, avt chair
[09:58:54] <gorryf> Magnus: There is work in this space to look at adaptive systems...
[10:00:00] --- admcd has left: Disconnected
[10:00:02] <gorryf> Mark H: I am doing very high-speed transfers in a project with Joderal bank, Manchester, UK - very high speed (gbps) telemetry of interferometry data. DCCp is nice in this space.
[10:00:29] <gorryf> --- A VoIP variant of TFRC - Sally Floyd ---
[10:01:13] <gorryf> (unsubmitted ID)
[10:02:05] <gorryf> * Issues for VoIP traffic:
[10:03:06] <gorryf> There was an IAB document that voice traffic should have fairness in TFRC in terms of bytes, not packets.
[10:03:14] --- Ted Faber has left
[10:05:08] --- admcd has joined
[10:05:13] <gorryf> This is implemented in NS and is fair to TCP flows that use 1500B packets, for packet flows with more than 10ms between packets
[10:06:06] <gorryf> Router limitations have changed - bandwidth is a limitation now - router processing power was a strong limiter (not now) but will return as routers increase in speed.
[10:06:23] <gorryf> Collin P: there are people doing VoIP with 5ms packets.
[10:06:37] <gorryf> sally F: they don't get benefit from this - but that's Ok
[10:06:49] <gorryf> Tom P: I'm not aware of such apps.
[10:06:57] <gorryf> Collin P: Broadvoice.
[10:07:25] <gorryf> * VoIP fainess:
[10:07:28] <gorryf> 3 line change to packet
[10:08:18] <gorryf> processing that would allow this (considers packet header on wire - approx - assume 40B)
[10:09:00] <gorryf> Incentive to not use excessively small packets (most we knew about until 10 mins ago would be OK)
[10:09:43] <gorryf> You should design anyway in the general Internet for 10ms or so of internet delay - this is normal.
[10:09:56] <gorryf> Aaron: Why not use the actual header size?
[10:10:12] <gorryf> SallyF: You can use real size (it says in the spec).
[10:10:30] <gorryf> Aaron: It could be much bigger too!
[10:10:40] <gorryf> SallyF : Factor of 2 makes little difference
[10:10:52] <gorryf> AAron: is it a strict minimum?
[10:10:56] <gorryf> Sally F: Yes.
[10:11:05] <falk> (That was Steve Casner, not me)
[10:11:09] <gorryf> Tom P: 10ms can get skew.
[10:11:29] <gorryf> 9ms is OK then :-)
[10:11:56] <gorryf> * standard TFRC..:
[10:12:19] <gorryf> * VoIP TFRC plot:
[10:13:09] <gorryf> vertical axis == packet number.
[10:13:22] <gorryf> Aaron: How do you tell VoIP session does well?
[10:13:59] <gorryf> Sally F: It's not as good as with no sharing.
[10:14:33] <gorryf> Collin P: are you going to talk about packet size?
[10:14:37] <gorryf> Sally F: Yes
[10:14:48] <gorryf> * Measuring Congestion:
[10:17:47] <gorryf> Ted: is this normalised as a distribution?
[10:18:10] <gorryf> sally F : we downloaded with know MTUs from web-servers....
[10:18:49] <mallman> "because i like it better". excellent.
[10:19:02] <mallman> and, someone should do these extensions to the measurements that sally suggests.
[10:19:04] <gorryf> There are complex interdependencies that impact things RED in packet) (REd in byte) (Drop-tail) (AQM) - all these flavour the results
[10:19:51] <gorryf> Colin P: The simulations tend to use large packets (20-30B of data is more normal)
[10:20:03] <gorryf> * Faster Restart after idle
[10:21:15] <mallman> lost audio
[10:21:27] <mallman> got it
[10:21:46] <gorryf> New bit: quadruple instead of double the sending rate (work to be done) - "Clearly fine" -- but not yet investigated for some cases... in the draft.
[10:22:09] <gorryf> Which WG is this?????
[10:22:20] <gorryf> - need to think about who should do this work.
[10:22:25] <gorryf> * The next step:
[10:23:37] <gorryf> Case for more than doubling sending rate per PRTT. This is work in progress - it needs more investigation.
[10:23:46] <gorryf> * The state of TFRC in NS
[10:24:04] --- csp has left
[10:24:21] <gorryf> WARNING: VoIP varient added, and more work is needed to add some of the new things (CCID3 is ahead).
[10:24:55] <gorryf> TFRC Packets on the wire in NS don't have packet headers (added to length) - code needs review.
[10:25:08] <gorryf> Aaron: What about Padding?
[10:25:13] <mallman> comment: faster restart be coupled with faster slowdown when the faster start up induces congestion
[10:26:01] <mallman> if you quadruple then it seems that you should have to backoff more (like by 1/4 ratehr than by 1/2)
[10:26:34] <gorryf> >>> Aaron- do you want to say above <<<
[10:26:38] <gorryf> Padding can be used to probe. There are ways to do this that ensure only a small fraction of bandwith are padded.
[10:26:53] <mallman> someone, please
[10:27:42] <Jukka Manner> Comment from Dado: In one of your e-mails in the list you write about modifying the TCP response function. Could you say a few words about how you plan to change it?"
[10:28:08] <gorryf> Sally F: *Response to Mark" "Yes"
[10:28:11] <mallman> good
[10:28:13] <mallman> i am happy
[10:28:14] --- Ted Faber has joined
[10:28:18] <mallman> with that answer
[10:28:25] <mallman> i'll read the draft
[10:29:20] <gorryf> Sally F: Response It's not much more optimistic than the most extreme TCP out there.
[10:29:26] <gorryf> Aaron closes.
[10:29:29] --- Ted Faber has left
[10:29:49] <gorryf> Aaron: repopens - we need to see way forward.
[10:29:56] --- admcd has left
[10:30:03] <gorryf> Need to revise after WGLC comments
[10:31:15] <gorryf> CCID revs; VoIP; Mobility (new discuss on list); TFRC discussions (could be followed in this WG perhaps); Should continue discussion of VoIP apps etc using DCCP as inputs to User Guide.
[10:31:33] <gorryf> Move to next layer of problems...
[10:32:04] <gorryf> AM: Why don't you put the protocol specs to AD Review. - This is useful to me!!
[10:32:13] <gorryf> Speak to Chair.
[10:32:31] <gorryf> Eddie - may be one further release.
[10:32:39] --- mallman has left
[10:33:10] <gorryf> Collin P: To give the WG CHANCE TO ACTUALLY READ this.
[10:33:34] <gorryf> Meeting finish (really this time)
[10:33:35] --- falk has left
[10:33:44] <gorryf> Slides were at: http://www.isi.edu/~falk/dccp/ietf-61-dc/
[10:33:50] --- Dado has left
[10:33:50] <gorryf> Scribe leaves too :-)
[10:35:42] --- gorryf has left: Disconnected
[10:37:10] --- jishac has left
[10:40:28] --- yjs has left
[10:41:59] --- gorryf has joined
[10:42:21] --- gorryf has left: Disconnected
[11:17:58] --- Jukka Manner has left
[11:18:52] --- gorryf has joined
[11:53:57] --- gorryf has left: Disconnected
[11:57:31] --- gorryf has joined
[12:22:02] --- gorryf has left: Disconnected
[12:30:50] --- gorryf has joined
[12:36:17] --- gorryf has left: Disconnected
[12:38:03] --- gorryf has joined
[12:41:49] --- gorryf has left
[14:53:48] --- mikeb has joined
[14:59:47] --- mikeb has left
[21:13:17] --- loughney has joined
[21:13:51] --- loughney has left