On 7/15/2015 7:51 AM, Karen Elisabeth Egede Nielsen wrote:
> Hi,
>
> Please find a very few comments to the document. Nothing major. Please use
> if you see fit and only then :-)
>
> Section 1: End First Paragraph:
>
> Here it is said that a transport service feature may be minimal latency.
> Opposed to the other features listed here,
> like e.g. in-order or reliable delivery, then minimal latency seems a more
> delicate obtainable feature; How one best obtain it
> within the services provided by a certain transport protocol, may depend
> quite heavily on the application traffic pattern (unless CPU and network
> resources are unlimited).
> Also minimal latency is not a feature which any of the protocols described
> in the document has within its list of features (I think) or
> are you thinking minimal latency and best effort transport service (like
> UDP) - Or are you thinking some smart protocol of the future which will
> deduce how to best
> provide a minimal latency service for a particular application flow over a
> specific E-to-E path ?
FWIW, UDP doesn't minimize latency; it (arguably) minimizes the latency
created by the transport layer at the expense of ordered, reliable
delivery and congestion control.
So there are several levels of the latency issue:
- minimize the latency ADDED by the transport layer
- reduce the latency seen by the app
(which can involve more active interaction with the network
layer, anticipation, etc.)
Note also that latency is not a single metric nor a meaningful
standalone metric:
1. latency between two parties is a property *of a message*,
i.e., it requires knowing the message size
2. latency includes both basic and higher order effects;
the basic is "delay", the higher order include "jitter" etc.
Many common delay-sensitive use cases are really mostly
jitter sensitive.
...
> I am not sure if Connection oriented and Feature negotiation should be
> split into two features ?
If you don't share state (i.e., what we tend to call a "connection"),
what is the meaning of feature negotiation?
...
> Disabling Nagle does not always give the lowest latency and further then I
> think that we are missing the good side of Nagle in the present text.
Nagle reduces the number of small packets at the expense of introducing
transport delay. Turning it off increases the number of small packets
and reduces the transport delay.
Although it's theoretically possible for the larger number of packets to
cause delays larger than those that Nagle aggregation would induce, in
practice the Nagle delays are several orders of magnitude larger.
Using byte-based congestion control, the larger number of packets would
have no effect. Using packet-based congestion control, the larger number
of packets would reduce latency (by opening up the window faster,
keeping it open longer, etc.) unless the increased number of packets
itself is the bottleneck.
So the general assumption that turning off Nagle will reduce latency
should be reasonable. Do you have a counterexample seen in the wild?
Joe
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
