Are you saying hop-by-hop reliability is not needed? A received message
is useless unless all fragments are reliably received.
If indeed hop-by-hop reliability is needed, then the link layer analogy is
unfortunately not right.
-s
On Mon, 6 Apr 2009, Bruce Lowekamp wrote:
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
