draft-various-eimpact-arch-considerations.md | draft-various-eimpact-arch-considerations-welzl.md | |||
---|---|---|---|---|
skipping to change at line 675 | skipping to change at line 675 | |||
protocol and system design. Further work in detailing this guidance | protocol and system design. Further work in detailing this guidance | |||
would also be useful. | would also be useful. | |||
It is likely that there is increased attention to resiliency in the | It is likely that there is increased attention to resiliency in the | |||
future, given for instance the increased importance of the tasks | future, given for instance the increased importance of the tasks | |||
supported by networks or the potentially increasing frequency of | supported by networks or the potentially increasing frequency of | |||
natural disasters as a result of global warming. | natural disasters as a result of global warming. | |||
## Transport {#transport} | ## Transport {#transport} | |||
Transport protocols are the flexible tools that make it possible for | Transport protocols make it possible for | |||
communication flows between parties to adjust themselves to the | communication flows to adjust themselves to the | |||
dynamic conditions that exist in the network at any given time: | dynamic conditions that exist in the network at any given time: | |||
available bandwidth, delays, congestion, the ability of a peer to send | available bandwidth, delays, congestion, the ability of a peer to send | |||
or receive traffic, and so on. Depending on the conditions, an | or receive traffic, and so on. Depending on the conditions, an | |||
individual flow may carry traffic at widely different rates, may pause | individual flow may carry traffic at widely different rates, may pause | |||
for some time, etc. Various higher-level transport solutions may also | for some time, etc. Various higher-level transport solutions may also | |||
cache or pre-fetch information. | cache or pre-fetch information. | |||
This behavior has an effect on sustainability as well, e.g., in | This behavior has an effect on sustainability---e.g., in | |||
what periods the endpoint and network systems are active or when they | what periods the endpoint and network systems are active or when they | |||
could be in reduced activity or sleep states. | could be in reduced activity or sleep states. | |||
Cellular networks and mobile links can scale their energy usage based on load and enter a low-power state when a traffic flow ends. Thus, in theory, the faster the data is transferred, the faster the device transmission/reception functions can enter a low-power state. | Cellular networks and mobile links can scale their energy usage based on load and enter a low-power state when a traffic flow ends. Thus, in theory, the faster the data is transferred, the faster the device transmission/reception functions can enter a low-power state. | |||
### Motivation | ### Motivation | |||
Transport behavior would have a possibility of impacting how much | Transport behavior would have a possibility of impacting how much | |||
downtime or sleep can be had in the communication system, either on | downtime or sleep can be had in the communication system, either on | |||
the end systems or routers or other equipment in between. The savings | the end systems or routers or other equipment in between. The savings | |||
can be significant, at least in wireless systems. | can be significant, at least in wireless systems. | |||
Improvements through transport behavior are only useful if the | Improvements through transport behavior are only useful if the | |||
skipping to change at line 705 | skipping to change at line 704 | |||
can be significant, at least in wireless systems. | can be significant, at least in wireless systems. | |||
Improvements through transport behavior are only useful if the | Improvements through transport behavior are only useful if the | |||
involved systems have power proportionality. | involved systems have power proportionality. | |||
### Analysis | ### Analysis | |||
A critical issue is the tradeoff involved in sending traffic. As | A critical issue is the tradeoff involved in sending traffic. As | |||
argued in {{NotTradeOff}}, reducing | argued in {{NotTradeOff}}, reducing | |||
the amount of time the endpoints and the network are active can | the amount of time the endpoints and the network are active can | |||
sometimes help save energy, e.g. in case the receiver is connected | sometimes help save energy. As a result, in general, delivering information as rapidly as possible would appear to be desirable. | |||
over a WiFi link. Similar logic applies for any technology that has a | ||||
certain degree of energy proportionality, e.g. cellular | ||||
communication. As a result, in general, delivering information as | ||||
rapidly as possible would appear to be desirable. | ||||
On the other hand, bandwidth-intensive applications can influence | On the other hand, bandwidth-intensive applications can influence | |||
other applications or users by presenting a significant load on the | other applications or users by presenting a significant load on the | |||
network, and consequently reducing capacity available for others, or | network, and consequently reducing capacity available for others, or | |||
increasing buffering (and with it, latency) across the network | increasing buffering (and with it, latency) across the network | |||
path. For an application with intermittent data transfers, such as | path. For an application with intermittent data transfers, such as | |||
streaming video, this would seem to speak in favor of sustained but | streaming video, this would seem to speak in favor of sustained but | |||
lower-rate delivery instead of transmitting short high-rate bursts {{Sammy}}. However, this | lower-rate delivery instead of transmitting short high-rate bursts {{Sammy}}. However, this | |||
is in contradiction with the energy-saving approach above. Thus, the | is in contradiction with the energy-saving approach above. Thus, the | |||
tradeoff is: should data be sent in a way that is "friendly" to others | tradeoff is: should data be sent in a way that is "friendly" to others | |||
skipping to change at line 735 | skipping to change at line 730 | |||
of other traffic. For non-urgent data transfers, the IETF-recommended | of other traffic. For non-urgent data transfers, the IETF-recommended | |||
default approach is the opposite: the LEDBAT congestion control | default approach is the opposite: the LEDBAT congestion control | |||
mechanism {{RFC6817}}, which is designed for such use, will always | mechanism {{RFC6817}}, which is designed for such use, will always | |||
"step out of the way" of other traffic, giving it a low rate when it | "step out of the way" of other traffic, giving it a low rate when it | |||
competes with any other traffic. Alternatively, if the goal is to | competes with any other traffic. Alternatively, if the goal is to | |||
reduce energy, such traffic could be sent at a high rate, at a | reduce energy, such traffic could be sent at a high rate, at a | |||
strategically good moment within a longer time interval; this would | strategically good moment within a longer time interval; this would | |||
give network equipment an opportunity to enter a sleep state in the | give network equipment an opportunity to enter a sleep state in the | |||
remaining time period within the interval. | remaining time period within the interval. | |||
Perhaps the issue is that the transport behavior (as with many other | Perhaps transport protocols should, in the future, | |||
things) needs to take into account multiple parameters. For example, | take energy into account in addition to the many other inputs they decide upon. For example, it is possible that a non-urgent data transfer would send as much as possible as soon as possible when | |||
it is possible that a balanced transport algorithm would be able to | at least one of the links along the path is known to be power proportional (e.g., a cellular link), while tracking buffer | |||
send as much as possible as soon as possible, while tracking buffer | growth from transmission delays to scale back if delay should occur. Such ideas remain to be confirmed with experiments, however. | |||
growth from transmission delays and scaling back if there's any buffer | ||||
growth. This remains to be confirmed with experiments, however. | ||||
Similarly, caching and pre-fetching designs need to take into account | Similarly, caching and pre-fetching designs need to take into account | |||
not only the likelihood of having acquired the right content in memory, | not only the likelihood of having acquired the right content in memory, | |||
but also the sustainability cost of possibly fetching too much or the | but also the sustainability cost of possibly fetching too much or the | |||
timing of those fetching operations. | timing of those fetching operations. | |||
In general, information about the impacts of loading or not loading | In general, information about the impacts of loading or not loading | |||
the network with additional traffic, and whether a certain sending | the network with additional traffic, and whether a certain sending | |||
pattern enables power savings through sleep modes, would be beneficial | pattern enables power savings through sleep modes, would be beneficial | |||
for the communicating endpoints. Mechanisms for making such | for the communicating endpoints. Mechanisms for making such | |||
End of changes. 5 change blocks. | ||||
15 lines changed or deleted | 8 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |