Opened 7 years ago

Last modified 2 years ago

#745 open enhancement

utp support?

Reported by: guest Owned by: zzz
Priority: trivial Milestone: undecided
Component: router/transport Version: 0.9.2
Keywords: performance Cc:
Parent Tickets:

Description

torrenting has a transport protocol called utp (u as in utorrent) which allows peer to peer transfers, while allowing the computer to always have plenty of bandwidth for web browsing or whatever else it needs. if it is even possible to transport i2p over this protocol, it may be a useful idea to allow casual users to have i2p running but still have uninterrupted web use

Subtickets (add)

Change History (8)

comment:1 Changed 7 years ago by zzz

I'm working on per-destination priority as described in #720

There may be other benefits to utp, but I don't know if it's the best way to solve the priority problem. I haven't looked at it in a while.

comment:2 Changed 7 years ago by zab

The closest equivalent to UTP would be SSU; #720 addresses that only partially as the OP is referring to other applications on the box, not other applications within i2p. The built-in backoffs in SSU should (speculating here) do the job.

@OP: i2p is just so different than regular torrenting that it's hard to answer this question.

comment:3 Changed 7 years ago by guest

I'm not sure if i didn't make myself clear, or if i am misunderstanding you. This is to allow other web applications on the same computer to always have priority, with i2p taking the rest of the bandwidth then a small amount unused to allow for changes. So the user can set i2p to use their full bandwisth while still ensuring that they can will always be able to use the internet freely.

comment:4 Changed 7 years ago by zab

@guest: when you say "web applications" you mean one thing, when a developer hears "web applications" it means another thing. That's the source of the misunderstanding.

comment:5 Changed 7 years ago by zzz

Yeah, the association with torrents confused me... I was thinking to use UTP for i2psnark, for it to play nicer with other I2P traffic.

You did say "transport I2P over this protocol". Zab's ticket #742 is related, as an alternate way for I2P to "back off".

I suspect that SSU does a poor job of utilizing available bandwidth. Most of my efforts on SSU are in making it better and faster. That may ultimately make it more of a bandwidth hog. It would be helpful to review SSU's congestion control, keeping in mind techniques used by other protocols including UTP.

Ref: https://secure.wikimedia.org/wikipedia/en/wiki/Micro_Transport_Protocol

comment:6 Changed 5 years ago by str4d

Today I received an anonymous I2P-Bote message about this ticket:

Many years later, I've discovered a more descriptive description of what I was trying to describe: https://datatracker.ietf.org/doc/rfc6817/
But it seems guests can't comment on trac any more :(

Is the ticket still relevant, and does this link add anything to it?
It's less protocol-specific to torrenting, as very few applications need bandwidth limits
configuring, torrents, i2p, and freenet being notable exceptions.

The linked RFC 6817 is "Low Extra Delay Background Transport (LEDBAT)".

comment:7 Changed 4 years ago by str4d

  • Keywords performance added
  • Milestone 0.9.9 deleted

comment:8 Changed 2 years ago by zzz

  • Milestone set to undecided
  • Status changed from new to open
Note: See TracTickets for help on using tickets.