dccp@conference.ietf.jabber.com - 2003/03/19

[10:16] %% carlalf has arrived.
[10:20] %% carlalf has left.
[10:23] %% jishac has arrived.
[10:25] * jishac has changed the subject to: agenda bashing
[10:25] <jishac> http://www.ietf.org/ietf/03mar/dccp.txt
[10:27] <jishac> Aaron Falk:
[10:27] <jishac> Plans:
[10:27] <jishac> * Detail Spec Review
[10:27] <jishac> * Public Design Review
[10:28] <jishac> ^ on agenda for vienna
[10:28] <jishac> * Quality Implementations
[10:28] <jishac> Issues:
[10:28] <jishac> * Lack of understanding of spec
[10:29] <jishac> hopefully will be helped by the reviews
[10:29] <jishac> Milestones:
[10:29] <jishac> Apr 03 - spec
[10:30] <jishac> changed to Dec 03
[10:30] <jishac> June 03 - User guide to Feb 04
[10:31] <jishac> Public Review:
[10:31] <jishac> - Next IETF
[10:31] <jishac> - Chaired by IAB rep
[10:32] <jishac> - Looking for cross discipline review
[10:32] <jishac> (more details on mailing list)
[10:32] %% mallman has arrived.
[10:32] <jishac> Open Technical Issues:
[10:32] %% mallman has left.
[10:33] <jishac> - Header only checksum
[10:33] <jishac> -Mobility
[10:34] <jishac> (needs more community input)
[10:35] <jishac> Open issues to remain open:
[10:35] <jishac> (Punting on)
[10:35] <jishac> - RTP optimizations
[10:35] <jishac> - LFNs
[10:36] <jishac> - TFRC variable packet sizes
[10:37] <jishac> <?< What exactly is the header problem
[10:37] <jishac> >AFalk> Will be answered in next presentation
[10:38] * jishac has changed the subject to: Spec Issues Summary - Eddie Kohler
[10:39] <jishac> ---
Partial Checksums
[10:39] <jishac> . purpose is to deal with corrupt data, possibly use it (audio, video)
[10:40] <jishac> . handle with congestion control
[10:40] <jishac> . concerns
[10:40] <jishac> .. link layer checksums
[10:40] <jishac> ... tend to be stonger than most others
[10:41] <jishac> ... l-layer will it support p.checksums
[10:41] <jishac> <?< Yes, udp-lite and wireless links
[10:43] <jishac> <<Alison< One of the optimizations isn't partial but no checksum, and that's why the uper stuff works, and it has been frowned on (delivering corrupted bits)
[10:44] <jishac> <<<Charles M< Corp. Input: Intersted in strong end to end checking of block IO, just a datapoint
[10:45] <jishac> <<<?< Are your reasons for doing this identical to UDP light?
[10:45] <jishac> > Yes
[10:46] <jishac> << Stewart Brians< {Lost due to blue sheet}
[10:47] <jishac> <<?< Same goals of UDPLight, but also the ability to seperate CC is very important and useful
[10:47] <jishac> <Alison< Need to have a better reason than this is cool
[10:47] <jishac> > Think that is Congestion vs. corruption
[10:48] <jishac> < Excelent
[10:49] <jishac> <<S Floyd< Open issues on how to deal with corruption detection?
[10:50] <jishac> <?< Encryption Authenication
Authentication is an issue b/c there is no Auth. method that deals with corruption
Need to think about that
> Not a killer objection
< Agrees
[10:51] <jishac> <??< Secure RTP - [Look at it?]
[10:52] <jishac> <Alison< Reitterating [requested by Falk]: [need to write some of this down basically]
[10:53] <jishac> <?< Seems worth it, but we shouldnt block on it
<Randy Basin< Does allowing partial checksums, causes problems with authentication, if the data is corrupted
[10:54] <jishac> < [Is it a problem authenticating the upper layers - where the data came from]
[10:55] <jishac> <<{Multiple, ?, ??, Alison, Speaker}< Yes
[10:55] <jishac> > One way to work with this is that if your using Authenication, then you MUST set this to 1 (full header)
[10:55] %% mrose has arrived.
[10:56] <jishac> <?< There may be an app that could use authenication in a unconventional way, and we may want to leave that option open
[10:58] <jishac> <> [concern that the app doing auth. and the app requesting p.checksum may be different]
<Pasari<
[10:58] <jishac> [Lost conversation]
[10:59] <jishac> Back to the presention
[10:59] <jishac> [.... or not]
[11:00] <jishac> <???< Clarificaion in spec, if checksum is end-to-end it needs to be specified
[11:00] <jishac> >
[11:00] <jishac> Link layer interactions
[11:03] <jishac> <??< LL may try several times and then pass packet up even corrupted, although I don't know of any commercial versions of such
[11:03] <jishac> . What if DCCP had a link corrupt bit
[11:03] <jishac> [Hypothetical link layer discussion BTW]
[11:03] <jishac> .. Init to 0
[11:04] <jishac> .. Bit flipped in transit
[11:05] <jishac> <?< Cant use this bit as a difinitive statement
[11:07] <jishac> <??< Is a link CRC being used still? Partial CRC's
> Yes
< Big problem with this, b/c addess can be corrupt and you send it to the wrong place
[11:07] <jishac> [Dpm
[11:08] <jishac> [Don't understand the tech details, basically this is dangerous over the entire path, possible for last link... maybe]
[11:10] <jishac> Intermediate checksum values
[11:11] <jishac> <?< Can see apps that utilize the various values
Complexity seems like the major issue
[11:14] %% falk has arrived.
[11:14] <jishac> Optional Paylod Checksum
[11:14] <jishac> <??< Aggrees to extending the payload length
[11:15] <jishac> <?< Likes the notion as well
[11:16] <jishac> When are packets received
[11:17] <jishac> . Ack vector and options serve a tripple duty
[11:18] <jishac> .. Inform CCID, DCCP, and APP(via api) of los
[11:18] <jishac> s
[11:19] <jishac> .. possible new ack vector, counter, or just punt until we have better API experience
[11:19] <jishac> Mobility
[11:20] <jishac> . DCCP endpoint moves
[11:20] <jishac> .. IPv4
[11:20] <jishac> .. added due to WG feedback
[11:21] <jishac> [There are security issues, that need to be addressed, as always]
[11:23] <jishac> [Current scheme is "Identification", although NATs propose a problem by editing port numbers]
[11:23] <jishac> <*< Mention of 'stun' [I think]
[11:24] <jishac> PBK (Purpose built keys)
[11:24] <jishac> . Requires Public Key crypto
[11:26] <jishac> [Aaron asked for a clarification of PBK in alison's absense, if aaron understood that explaination he can type it in ;)]
[11:27] <jishac> RTP Interactions
[11:27] <jishac> <?< Optimizations may make header compression more difficult
[11:28] <jishac> Long Fat Pipes
[11:28] <jishac> . Seqno are 24 bits long
[11:28] <jishac> .. enough?
[11:29] <jishac> . SN are per packet, 10 more bits for free compared to TCP
[11:29] <falk> pbk: - yogesh: send working group using a similar mechanism; problem
with pbk is generating both keys
[11:30] <jishac> <Mallman< We don't require TCP Friendlyness?
> correct
< so wondering if basing SN size on tcp friendlyness is the right thing to do
> non tcpf ccid are possible in the future
[11:32] <jishac> <<?< Plan for this case and plan on how to cope with massive windows (should it arrise in the future)
< possible to send a lot of packets in the future, or we may just have bigger packets
[11:35] <jishac> LFN Solutions
[11:36] <jishac> . Borrow TS option
. Increase SN size
.. can cause larger headers
[11:37] <jishac> [ need to advocate smaller headers, should do nothing for now]
[11:38] <jishac> Fragmentation
[11:38] <jishac> . Use IP frag
[11:38] <jishac> <??< Why not MTU discovery
[11:39] <jishac> > if App doesn't do it, need to handle fragments
<?< real solution should be app needs to do frag, and turn on MTU discovery
[11:40] <jishac> > Just closing the door on a possible extention
[11:40] <jishac> Reserved space / bits
[11:40] <jishac> . Use for CCIDs?
[11:41] <jishac> <?< Good idea, but may makes it hard for HCompression...
[11:42] <jishac> > In the case of TFRC, it's either 4 bits in the header, or an option, either way it's likely a problem for compression, but we'll hear from the HC folks
[11:43] <jishac> > Julia will talk about HC later
[11:44] <jishac> Quickies
. HC
[11:44] <jishac> . TFRC
. CODECs
[11:45] <jishac> <?< Does DCCP have the abiltiy to vary, modify TFRC's rate
[11:46] <jishac> Closing:
[11:46] <jishac> Mobility is the least baked, the rest it good, waiting on implementations
[11:47] * jishac has changed the subject to: Spec Issues Summary - Eddie Kohler
[11:47] * jishac has changed the subject to: CCID Issues Summary - Sally Floyd
[11:47] <jishac> Changes in CCID2: Tcp-like congestion control
[11:48] <jishac> Changes still to make:
[11:49] <jishac> . If there are changes to TCP CC, just assume you can use it here... so we don't have to keep updating both
[11:50] <jishac> (changes that are tied to the bytestream semantincs may need thoughtful consideration)
[11:51] <jishac> . ABC see how it may be incorporated
[11:52] <jishac> <m allman< Clarify
> Need to do a case by case analysis to see how to cary it over
[11:52] <jishac> Problems with CCID3 - TFRC CC
[11:53] <jishac> . optional use of ack-vector not fully specified
. use of ECN Nonce not fully specified
[11:54] <jishac> [Some wording changes to Ack vector in CCID3]
[11:54] <jishac> ECN nonce:
[11:56] <jishac> Rename "ECN N Option" to "Loss Interval" and extended it to allow upto 8 loss intervals
[11:56] <jishac> .. allows sender to more precicly verify feedback
[11:56] <jishac> .. means sender could do without the feedback if desired
[11:59] <jishac> <?,Eddie< Q from list: Manditory CCID; what's the point?
> So any sender/reciever can talk to each other
[12:01] <jishac> <?< If this is done as a stack then it should have a manditory CCID, if it is done as a compliment to the application then they are likely tightly coupled and it wouldn't be necessay
>Sally,Eddie> agree
[12:01] * jishac has changed the subject to: Users Guide/API Issues - Damon Lanphear
[12:03] * jishac has changed the subject to: DCCP profile for ROHC
[12:04] %% mallman has arrived.
[12:04] %% mrose has left.
[12:04] <jishac> Goal is to define a DCCP profile
[12:08] <jishac> All DCCP headers have a generic header followed by specific headers and options (header layout is shown)
[12:08] <jishac> Problems:
[12:09] <jishac> . Header length, [all are not explicit?]
[12:10] <jishac> . ACK context
[12:10] <jishac> . RTP SequenceNo
[12:12] <jishac> Conclustions:
Recomend:
. Make ACKs part of a generic header
. Seperate RTP (doesnt' change other fields)
[12:13] %% mallman has left.
[12:14] <jishac> <?< on Acks as generic header: CC assumes the full header length, not a clear cut issue
[12:15] <jishac> << Don't believe it's that tricky [didn't catch reason]
[12:17] <jishac> <<ROHC Chair< This should be done in the ROHC WG, but right now DCCP doesn't have critical mass in ROHC, there should be more input from the DCCP folks in ROHC
[12:17] * jishac has changed the subject to: Aaron on implementations
[12:17] <jishac> Implementations:
[12:18] <jishac> * ICIR
[12:18] <jishac> * SUN, ready by next IETF?
[12:18] <jishac> * RealNetworks
[12:18] <jishac> * Deval Mehta
[12:19] <jishac> Vladimir Moltchanov, Nokia
[12:20] <jishac> Other issues?
[12:20] <jishac> (open Mic)
[12:21] <jishac> <?< If we got rid of the p.checksum, we can extend the SN to 32 bits... Believes p.checksum is the right choice, but it's a clear tradeoff
[12:22] <jishac> <<??< Probably made the right choice
[12:22] <jishac> <<Eddie< rather have p.checksums than more bits in the SN
[12:23] <jishac> <?< Notes that nobody is really pushing for more SN bits in the header
[12:23] <jishac> > since no other input, take it to the list
[12:23] <jishac> > adjourn
[12:32] <jishac> ? = Mark Handley
?? = Colin Perkins
[12:32] <jishac> [Well I enjoyed talking to myself, I hope the archives are useful ;)]
[12:35] %% jishac has left.
[12:40] %% falk has left.