I'm not understanding what you mean by debit. Do you mean revoking some of the flow-control-receive-window after the fact? Can you explain? -=R On Thu, Dec 13, 2012 at 12:59 PM, Jonathan Ballard <dzonatas@gmail.com>wrote: > For wireless, an algorithm may provide semantic value. On the wire, that > value, or flow, is already present. I would like to say, replace SPDY's > Push/Pull semantic flow with credit and debit accounting. I thought we > already understood balances and currencies. > > One sample is Raspberry PI FTP box that runs on solar power. It appears > wasteful not to match power units to credit/debit the flow; when, we can > avoid energy demands spent on extra algorithms that achieve the same. Power > is sent over USB, so that is orthogonal to power over Ethernet. The > blackbox in this sample is the batteries. I can think of many explorations > projects to fine tune such accounting. > > My opinion, credit-only numbers lead to more permanent registries as trust > tokens develop. That means the blackbox converts into greybox, which may > not be desired at all. That means more resistance to SPDY. > > > On Thursday, December 13, 2012, Gabriel Montenegro wrote: > >> ** ** >> >> ** ** >> >> *From:* Jonathan Ballard [mailto:dzonatas@gmail.com] >> *…***** >> >> ** ** >> >> After I read it the question that was left was, "where is the debit >> rule?" If that question doesn't make sense then maybe "credit" isn't the >> real number word for flow control. >> >> Gab> Not sure I understand the comment. Could this be related to Eliot’s >> comment that the algorithm is clearly in the hands of the receiver? All the >> sender has to do to debit towards any available credit is to send as much >> of that credit as he needs to send. The actual over-the-wire(less) >> transmission dynamics, of course, are in the hands of the underlying TCP >> implementation (which would presumably heed congestion control rules, but >> that is opaque to HTTP 2.0).**** >> >> ** ** >> >> Thanks,Gabriel**** >> >
Received on Friday, 14 December 2012 00:07:42 UTC