[e2e] Question about RFC 2581

[Randall Stewart]

Henderson, Thomas R wrote:
>>My own opinion is that congestion avoidance should be 
>>implemented using
>>byte counting and that 1 SMSS should be added to cwnd after cwnd bytes
>>have been ACKed.  That is allowed in the current RFC.  
>>
>>In the revision, should this scheme be not only allowed but 
>>encouraged?
>>I only see advantages (mostly in terms of security) of this, not
>>disadvantages.  (The only disadvantage that really comes to 
>>mind is that
>>a touch more state must be kept... basically how much data has been
>>ACKed since we last bumped the cwnd.)
>>
>>I'd love to hear opinions on this. 
>>
> 
> 
> Not all split acks are malevolent.  For example, they are a component
> of Cisco's RBSCP implementation.
> 
> In fact, I think that one might be able to construct a satellite gateway
> that maintained true end-to-end semantics (no byte of data acked before
> the true receiver acked it), and also adhered to the principle of not
> returning more than one (split) ack for every segment successfully
> received at the gateway, and approach the performance of TCP-splitting
> gateways.


Well.. being someone behind the scenes of RBSCP :-D I will comment
on this..

The whole point of RBSCP was to NOT break the E-2-E semantics of
a connection and at the same time NOT save any state in the routers
aka no per-flow-state...

If I grok what you are saying above I don't see how you could
"speed" the satellite connection up...

RBSCP now does this

TCP-Sndr - Router --Sat-modem ---//// -- Sat-modem - Router - TCP-rcv

------Data---->
               -----Tunnel--->------------------------->
                                                       -----Data--->
                                                       <-----ACK----
               <------------ACK-------------------------
<--ACK
<--ACK
<--ACK
(split times)

Now if I grok your statement you would take out
the split acks above, which are used to try to
get the sndr to open its window faster. Note that
the end-2-end semantics are preserved.. just that the ack
is split into multiple pieces...

If you take the split ack's out you wont get the sender to
increase the cwnd any faster..

If SCTP is in place its a different picture, since appropriate
byte counting is built into SCTP. However there is a extension
floating around for SCTP that provides a

                 <-----SACK---------------------
   <---SACK+PKTDROP

The packet drop in this case is used by the router to identify
the bandwidth characteristics of the current outbound satellite
tunnel. This allows SCTP to make adjustments to the send window.

Which by the way makes SCTP scream over a satellite and still
fair-share the bw...

Of course all of this only works well if you get the send and receive
windows up large enough on each side as well.... For SCTP thats
not to much of a problem, since the implementations our newer and
most implementors have followed my recomendation to put your rwnd/swnd
as LARGE as possible (and no SCTP is not subject to the slipping
in the window attack). For TCP implementations its more probablamatic..
since many impelementations set the windows around 8 or 16k... sometimes
32 if your lucky :-D

R
> 
> Tom
> (ducking for cover)
> 
> 


-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)