Re: [Taps] TCP components

[Mohamed Oulmahdi <[e-mail]>]

Hi,

On Jun 11, 2015 4:11 PM, "Mirja Kühlewind" <[e-mail]>
wrote:
>
> 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...

 I don't understand this delay optimization. Is it thanks to Nagle's
algorithm or for the possibility of its deactivation? Because it's known
that this algorithm increase delay and so became unsuitable for
delay-sensitive applications...
>
>
>>
>>> - 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps