Re: [Taps] TCP components

[[e-mail]]

We seem to agree mostly, a few small comments in-line

> 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.
>
So would we have the same text in UDP, SCTP, etc?
>>
>>> 	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?
>
Only that TCP combines the segment data with the pseudo header from IP to
perform the checksum. For IPv4, this also assumes that each IP datagram
also passes the IP datagram checksum for each datagram (fragment)

>>
>>> - 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.
>
I'd prefer to be clear on this.
>
>>
>>> - 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
>
>
Gorry