Hi Gorry,
see below.
- Limited control over segment transmission scheduling (Nagle's
algorithm):
This allows for delay minimization in interactive applications.
GF: Not quite - To me, it prevents increased delay from the TCP protocol.
It doesn't really control anything to reduce delay.
Yes, I think we wanted to say the same thing here; don't really see the
difference...
- Port multiplexing, with application-to-port mapping during connection
setup:
GF: Thinking on this, is application-to-port mapping really a TCP
function? port-mapping is similar in other transports, and doesn't really
have any different support in TCP (contrast to the Service Code in DCCP)
No it's not specific to TCP but it's still something you get when you use TCP
and that's what we wanted to document here.
Note that in the presence of network address and port translation
(NAPT),
TCP
ports are
in effect part of the endpoint address for forwarding purposes.
GF: This is the case only for those middle boxes that do NAPT,
load-ballancing etc, saying they are part of the endpoint address is to me
confusing forwarding by middle boxes from forwarding by routers - I'd
prefer to be more careful here.
I agree that we should be careful here about the wording. However this was only
a note to explain slightly better what we had in mind here.
- Full reliability based on ack-based loss detection and retransmission:
Loss is sensed using duplicated acks ("fast retransmit"), which places a
lower
bound on
the delay inherent in this approach to reliability.
GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used in
SCPS-TP and probably doesn't nee dot be mentioned).
I'd say DupACK and RTO is both ACK-based loss detection where in the latter case
no ACKs are received for a certain time. However we can add both explicitly
here. What we probably should mention is that RTO puts a maximum bound on the
delay. I agree that SACK should probably be mentioned as well here because this
again helps speeding up the retransmissions and therefore helps reducing delay
by head of line blocking.
- Error detection based on a checksum covering the network and transport
headers
as well as payload:
Packets that are detected as corrupted are dropped, relying on the
reliability
mechanism
to retransmit them.
GF: True (actually packets header checks and data segments + pseudo header)
Sorry, what do you mean by pseudo header here?
- Window-based flow control, with receiver-side window management and
signaling
of available window:
Scaling the flow control window beyond 64kB requires the use of an
optional
feature,
which has performance implications in environments where this option is
not
supported.
GF: Does environment mean path? or something else?
Both option stripping on the path or no support of the receiving end point. Can
make this more clear.
- Window-based congestion control reacting to loss, delay, retransmission
timeout, or
an explicit congestion signal (ECN):
Most commonly used is a loss signal from the reliability component's
retransmission mechanism.
TCP reacts to a congestion signal by reducing the size of the congestion
window;
retransmission timeout is generally handled with a larger reaction than
other signals.
GF: Generally? Shouldn't RTO imply loss of path state and always result in
a larger reaction? (RTO back-off for instance).
In principle yes, but you could easily also implement an congestion control
algorithm there the window is set to minimum for every dupACK. The 'generally'
is because there is not the one and only congestion control in TCP and therefore
you never know what people actually implement.
Mirja
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
