[Sis-SCPS-INTEREST] Re: ZeroWindow segment

[Eric Travis]

Miguel,

Pat has hit the nail on the head...

If your clients can set their default socket buffers to be approximately
a bandwidth-delay
product then a  single transport proxy (gateway) may provide you r
clients with a
performance improvement.


This performance increase would be from 2 factors:

  o  Flow controls windows will now be large enough to prevent
artificial window limiting
      (Incidentally, I've observed that Linux hosts are pretty good at
auto-tuning their
      receive buffers, but that really doesn't help the clients with
Windows desktops)

  o  The split connections will facilitate more rapid recovery from
congestion events
      in the network - increasing the chances of your client's flows
getting a fairer share
      of the bottleneck bandwidth.

However... without a peer SCPS-TP entity, your clients won't have the
benefit of
SNACKs (as well as losing the ability to use SACK unless the SCPS-TP proxy
implementation supports SACK).  This has the *potential* to negate the
above benefits
unless the path between your transport proxy and your clients is
relatively loss free
(both corruption-based and congestion-based sources of loss)

The transparent tuning of the send/receive transport buffers on both
sides of the transport
connection is where much of the benefit of a split-transport proxy
deployment. So if it is
at all feasible to deploy transport proxies on the client side, your
client's lives get easier
as there is no need to tune the client side socket buffers (which can be
difficult to coax on
some applications).

Eric


miggy1 at free.fr wrote:
> Thank you for your help Eric,
>
> I believe the problem is that I have only one Gateway. I would like to optimise
> the communication between a client that doesn't have a SCPS-TP stack and my
> Gateway :-p
> Is ther a way to use SCPS with only one Gateway that could improve TCP
> communications at the provider side (negociation of the supported skills and if
> possible SCPS-TP)?
>
> Thank you for the previous message wich explains well the establishment of a
> connexion.
>
> Miguel
>
>
> Selon "travis at globalprotocols.com" <travis at globalprotocols.com>:
>
>   
>> Miguel,
>>
>> You may indeed have connectivity/configuration problems with the gateway,
>> but I believe that your SCPS-TP gateways are interacting properly.
>>
>> I believe what you are seeing is the normal connection establishment
>> behavior
>> for the Reference Implementation of the SCPS-TP gateway.
>>
>> The end-to-end TCP flow is split into 3 pieces:
>>
>>
>>    http client ----------> local GW ----------> remote GW -------> http
>> server
>>
>> The local GW intercepts the SYN from the http client and immediately
>> opens a connection between the http client and itself (spoofing the http
>> server)
>> and then performs an active open to the http server on its own behalf;
>>
>> In order to prevent the http client from sending any data until the local GW
>> knows it has a connection to (who it thinks is) the http server, it
>> advertises
>> a zero window to the http client.
>>
>> When the local GW receives a SYN-ACK (and *maybe* a non-zero advertised
>> window)
>> in response to it's active open, it will send a window update to the
>> http client.
>>
>> The same thing happens between the local and remote GWs.
>>
>> If there is indeed a problem for the local or remote GWs to connect to their
>> "next hop" destination, you should receive a RST segment at the http client.
>>
>>
>> So, you should be seeing this zero-window advertised on the SYN-ACK from the
>> RI SCPS-TP gateway on all flows - even the successful ones.
>>
>>
>> Hope this helps understand what you are seeing.
>>
>> Eric
>>
>>
>>     
>
>
>