Re: [Tsvwg] early retransmit

[Randall Stewart <[e-mail]>]

Mark Allman wrote:
>>   "Research shows that a general reduction in
>>    the number of duplicate ACKs required to trigger fast retransmission
>>    of a segment to two (rather than three) leads to a reduction in the
>>    ratio of good to bad retransmits by a factor of three [Pax97].
>>    However, this analysis did not include the additional conditioning
>>    on the event that the ownd was smaller than 4 segments."
>>
>>I don't see how the condition of ownd < 4 segments matters. If 3
>>dupacks is more appropriate to due the amount of reordering, then
>>less than 3 isn't appropriate regardless of ownd.
> 
I had this same sort of thought as well.. I just could not
see the connection between ownd < 4...

> 
> Unless the pattern of reordering a connection experiences is
> effected by the amount of load that connection is placing on the
> network.  The Bennett, Partridge, et. al. study on reordering (ToN,
> 12/1999) suggests that reordering and congestion are linked (but, I
> do not think they analyzed that correlation at the connection
> level).
> 
> Maybe all that needs stated a bit better.  But, I think the point is
> still valid.  (And, you might be right... my point is really that we
> don't know.)
> 
> 
>>I prefer solutions which induce the possibility of 3 dupacks (or 4
>>missing reports for SCTP). 
> 
> 
> Well, that is best.  I like limited transmit.  And, you'll note that
> this ID is for the case when you don't have new data to send.  But,
> you knew that because...
> 

Yes, when you have enough data in the pipe things are fine.. its
for these cases where you don't that a problem arises.. in my
recent testing I have seen this A LOT in trailing packets in
my simulated satellite network... you end up always taking
a RTO if its in the last 2 or 3 packets that the drop occurs...
something not all that uncommon when you are looking at
2-6% error rates...surprisingly... I also have seen
this a lot when you approach the peer rwnd limit and
thus stop sending again..

I think in all my recent work almost all the RTO drops
were this form.. rwnd full & drop in last few packets OR
trailing edge of a transfer....

> 
>>Hari Balakrishnan's solution of sending zero-byte segments and
> 
> 
This does not help an SCTP case.. since you are not allowed
to send a data segment with zero bytes... I like using the
DSACK info (since SCTP has it :>) and combine this with
a limit on reducing your limit once for some time say
a RTT (only when you are in this state.. no data to send)...


> So, I'd be interested in hearing from people who understand these
> sorts of things... Given that I am going to form up a packet and
> send it across a network path, what is the marginal cost of adding
> data to that packet?  I.e., what is the delta in effort between a
> zero byte packet and a full packet?  (I realize that this is likely
> hard to quantify in any sort of general way.  But, is it "a lot more
> effort" or "not much more effort" or what?)
> 
> My gut says that in the general case we might as well dump data into
> the packet.
> 

Well, I am NOT an expert but I have been digging a bit deeper
into one of the Routers that is in the I-net.. and I don't
really think it makes that much difference if the packet
is 50 bytes or 1500 bytes.. you still have all of the
internal structures you must use in moving the packet through
the router... often times these are optimized to fit a full
MTU depending of course on how the packet is being switched
through the router... sometimes you can get by with smaller
pieces...depending on the type of forwarding that is going
on of course...

It would be worth doing a little lab work to see if you route
N fulls size segments through a network and contrast that with
N small segments.. does it make a huge difference... There will
be some.. but I don't know how much...

Maybe when I get a few cycles (don't hold your breath :-0) I will
set something up...I am interested in knowing this little gem.. for
at least one of the routers that is out in the world :-)

> 
>>Marco Mellia et al.'s solution of breaking segments into smaller
>>pieces are two ideas which I think deserve more attention.
>>Although these mechanisms may add _some_ load to the network, I
>>think more research is needed with these type of solutions.
> 
> 
> I agree that more research is needed.  No doubt.
> 
Yep... it still needs to be baked a bit...

> But, it comes down to a question of what is the unit that matters.
> Is it the number of bytes I throw into the network or the number of
> packets I inject?  (And, yes, I am sure the answer is "both". ;)
> 
> I think early retransmit sounds like a fine idea.  Digging a little
> deeper into one of my questions of this morning... What sorts of
> limitations should we place on the use of ER?  I think a possible
> approach is to say that you should use DSACK or Eifel or something
> in conjunction with ER to detect the cases when ER retransmitted
> spuriously.  And, if you figure that out then you have to stop using
> ER.


I like DSACK myself (as I said above :>)

R
> 
> 
>>I also think that more research is needed to determine what dupack
>>threshold is appropriate. It may be worthwhile to investigate the
>>use of a mechanism which begins with a conservative threshold, and
>>then gets adjusted over time. To start, DSACKs/Eifel/etc may be
>>useful for increasing the threshold.
> 
> 
>     Ethan Blanton, Mark Allman. On Making TCP More Robust to Packet
>     Reordering. ACM Computer Communication Review, 32(1), January
>     2002.
>     http://roland.grc.nasa.gov/~mallman/papers/tcp-reorder-ccr.ps
> 
>     Ethan Blanton, Robert Dimond, Mark Allman. Practices for TCP
>     Senders in the Face of Segment Reordering, February
>     2003. Internet-Draft draft-blanton-tcp-reordering-00.txt (work
>     in progress).
> 
>     Ming Zhang, Brad Karp, Sally Floyd, and Larry Peterson.  RR-TCP:
>     A Reordering-Robust TCP with DSACK, ICSI Technical Report
>     TR-02-006, Berkeley, CA, July 2002.
>     http://www.icir.org/bkarp/reordering-TR.ps.gz
> 
> I am sure others, too.
> 
> allman
> 
> 
> --
> Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
> _______________________________________________
> tsvwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> 


-- 
Randall R. Stewart
[e-mail] 815-342-5222 (cell phone)

_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg