Fortunately, reliability is not important for the overlay link protocol. It's a link layer.
Bruce On Mon, Apr 6, 2009 at 2:02 PM, Salman Abdul Baset <[email protected]> wrote: > > TFRC is a congestion control protocol. What is intended is a reliable > congestion control protocol over UDP, which does not exist as a > specification. Reliability cannot merely be sprinkled on top of TFRC or any > congestion control protocol. > > -s > > On Mon, 6 Apr 2009, Bruce Lowekamp wrote: > >> Yes, that's a valid option. Probably the right one at this point. In >> fact, the solution space as I last sent it out looks like: >> >> - stop and wait >> - simplified AIMD >> - TFRC >> - (TCP over UDP might go here if a draft existed) >> - TCP >> >> The argument has mostly been about the simplified AIMD. I kind of >> hate to lose it, but you're right, it will be a lot less controversial >> if we do. Actually, TFRC is a pretty flexible protocol itself, so we >> can probably just do something a bit more within that framework if we >> want to have options. >> >> stop and wait was always intended as maybe a development-type >> protocol, not a real deployable protocol (although it would work OK in >> a small office environment) >> >> Bruce >> >> >> On Mon, Apr 6, 2009 at 9:18 AM, Brian Rosen <[email protected]> wrote: >>> >>> Is "use TCP when it works, and TRFC when it doesn't" an answer? >>> Arguments like "it's too complex" don't work for me when we're talking >>> transport protocols that have to do congestion control, etc. Congestion >>> control is complex. >>> >>> Brian >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf >>> Of >>> Lars Eggert >>> Sent: Monday, April 06, 2009 5:20 AM >>> To: Bruce Lowekamp >>> Cc: Salman Abdul Baset; [email protected] >>> Subject: Re: [P2PSIP] Solution space for fragmentation, congestion >>> control >>> and reliability >>> >>> Hi, >>> >>> On 2009-4-6, at 6:07, Bruce Lowekamp wrote: >>>> >>>> We have the option of simpy saying "use TFRC." That will be good >>>> enough performance, and require relatively little specification since >>>> TSV has already put a lot of work into it. It's also a bit >>>> complicated. A lot more complicated than is really needed for most >>>> p2psip implementations/deployments. >>>> >>>> So the motivation of the other options was to provide simpler options >>>> that are going to provide enough performance for many/most >>>> deployments. >>> >>> I'd strongly urge you to use TFRC rather than rolling your own scheme. >>> Don't underestimate the validation effort that is required to ensure that >>> a >>> congestion control scheme is safe to deploy. This has all been done for >>> TFRC, and it must be done for any new scheme. >>> >>> Lars >>> >>> >> > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
