Re: [Taps] TCP components

[Mirja Kühlewind <[e-mail]>]

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