On Jan 11, 2008, at 11:40 AM, Matthew Toseland wrote: > On Friday 11 January 2008 08:34, Michael Rogers wrote: >> Robert Hailey wrote: >>> Rejecting new >>> requests would keep the data-transfer level traffic from being >>> starved. >> >> Yup, that makes sense as long as it also applies to local requests. > > Which it does, as of some weeks back. > > BTW robert, we do have a limit on the number of running requests: the > bandwidth liability limits. > > Now, is there any reason to prioritise different control messages > differently? > And do we want absolute priorities, or different timeouts (messages > will be > sent at t+100ms if they haven't been sent already at the moment, we > could > vary this by type), or both? > > For example: > > Group 0: > 100ms coalescing timeout. > Packet acknowledgments. > These need to be sent fairly quickly. > > Group 1: > 100ms coalescing timeout. > Various messages with short timeouts, or which we need to send > quickly for one > reason or another. > FNPAccepted > FNPRejectedLoop > FNPRejectedOverload > FNPDataInsertRejected > FNPSSKAccepted > FNPCHKDataRequest > FNPSSKDataRequest > FNPRecentlyFailed (can be sent at Accepted time, or later) > FNPInsertRequest > FNPDataInsert > FNPRejectedTimeout (counterpart of FNPDataInsert) > FNPSSKInsertRequest > FNPSSKAccepted > FNPSSKPubKeyAccepted > FNPOpennetAnnounceRequest > FNPOpennetDisabled > FNPOpennetNoderefRejected > FNPPing/FNPPong - ???? > FNPLinkPing/FNPLinkPong - ???? > FNPProbeRequest - ???? > FNPProbeRejected - ???? > FNPDetectedIPAddress - good to have this arrive soon after connect > FNPTime - ditto > FNPSentPackets - ditto > FNPDisconnect - good to have this arrive quickly as we may be > shutting down > UOMRequestRevocation > UOMSendingRevocation > FNPRoutingStatus > FNPSwapRequest/Rejected/Reply/Commit/Complete/Rejected - 60 seconds > timeout, > but IMHO we need these to move fast > > Group 2: > Messages which don't have particularly short timeouts. > 200ms coalescing timeout? Or even more? > allSent - not very important > missingPacketNotification - no short timeout, however we do want it > to arrive > soonish so we can complete the transfer; maybe include in the next > group??? > allReceived - important message, 60 second timeout > sendAborted - moderately important message, can go each way, 60 > second timeout > one way > FNPBulkSendAborted - long timeout (5min) > FNPBulkReceiveAborted - no timeout, dropped on completion > FNPBulkReceivedAll - no timeout, dropped on completion > nodeToNodeMessage - maybe treat this as bulk? > FNPDataFound - long timeout (2min) > FNPCHKDataFound - long timeout (2min) > FNPRouteNotFound - long timeout (2min) > FNPInsertReply - long timeout (2min) > FNPSSKDataFound > FNPDataInsertRejected - ?? > FNPInsertTransfersCompleted - long timeout (2min) > FNPOpennetCompletedAck - long timeout (2min) > FNPOpennetConnectDestinationNew - long timeout (2min) > FNPOpennetConnectReplyNew - long timeout (2min) > FNPOpennetAnnounceReply - long timeout (4min) > FNPOpennetAnnounceCompleted - long timeout (4min) > FNPOpennetAnnounceNodeNotWanted - long timeout (4min) > FNPOfferKey > FNPProbeTrace - ???? > FNPProbeReply - ???? > FNPLocChangeNotification > FNPRoutedPing/Pong > FNPVoid > UOMAnnounce > UOMRequestMain > UOMRequestExtra > UOMSendingMain > UOMSendingExtra > > Group 3: > Bulk data transfer. > 200ms coalescing timeout? Or even more? > (note these are all around 1kB, they should all behave similarly to > minimize > the available data for traffic analysis) > 200ms timeout? > packetTransmit > FNPBulkPacketSend > FNPSSKInsertRequest > FNPSSKDataFound > FNPSSKPubKey > > When we do decide to send a packet, we should send as big a packet as > possible, provided that this doesn't break the timeouts, so usually > we would > bundle some packet acks, some high priority messages which are past > their > timeout, some high priority messages which are not past their > timeouts, and > one big message. > > Another consideration: can delaying packets for coalescing cause us > to grossly > undershoot our bandwidth limit?
I like this schedule of groupings, but for lack of a point of reference I can't speak towards the coalescing delays. What do you mean by delay causing the bandwidth limit to be undershot? It seems to me that if (for example) the packetTransmitters use the same master throttle, then packets getting ahead of them would cause a trivial creep of the send queue, but that's it. -- Robert Hailey
