Re: [conex] ConEx as sender side only modification

[Matt Mathis <[e-mail]>]

One robust algorithm to audit loss is to look at sequences numbers and
count duplicate data.  Such an auditor will see every retransmission
(including twice lost and re-retransmitted segments), but it can't
tell if TCP later decided that they were spurious.

So the audit has to balance retransmissions, and not TCP's estimated losses.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay



On Fri, Mar 30, 2012 at 8:39 AM, Scheffenegger, Richard <[e-mail]> wrote:
>
> Bob,
>
> a minor nit-pick; even with SACK-enabled flows, you may underestimate the lost bytes from time to time. Whenever a retransmission is lost, the sender won't know about these further bytes that have lost.
>
> Unless, that is, the sender also implements lost retransmission detection (which is not standard, and only available in Linux, when the sender buffer is not empty).
>
> But I do agree with the spirit of your comment, SACK is good enough for conex to account the lost bytes. The deviation can be estimated by looking at the fraction of (sender side) timeout retransmissions (I think linux breaks them down even further) vs. total packets sent. That should be in the order of 10^-4 or lower even for bad links.
>
>
>
> Richard Scheffenegger
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Bob Briscoe
>> Sent: Donnerstag, 29. März 2012 18:11
>> To: Ingemar Johansson S
>> Cc: [e-mail]
>> Subject: Re: [conex] ConEx as sender side only modification
>>
>> Ingemar,
>>
>> For a Not-ECN-capable transport, SACK is fully accurate enough for the
>> sender to know every lost byte. That's the main reason ConEx is optional for
>> the receiver.
>>
>> For ECN-capable transport, using an un-modifed receiver is not so good. You
>> can use various strategies if you have to (a couple are given in the accurate
>> ECN draft).
>>
>> You will see Michael Menth's simulations later in the ConEx session show
>> how it's not so good with unmodified ECN-capable receiver.
>>
>> HTH
>>
>>
>> Bob
>>
>> At 11:16 14/11/2011, Ingemar Johansson S wrote:
>> >Hi
>> >
>> >Have not been able to follow the ConEx list in detail but reading
>> >http://tools.ietf.org/id/draft-briscoe-conex-initial-deploy-00.txt
>> >I can see that received side modifications are optional.
>> >This is of course interesting at least if consinder the normal server
>> >client architecture as it is easier to modify a million servers than a
>> >zillion clients.
>> >Assuming that I read right...
>> >How does it work with TCP, I know TCP
>> >modifications have been considered to make TCP echo back the exact
>> >correct number of ECN-CE to the server.
>> >Does this then mean that a TCP flow (unmodified
>> >TCP) will state a higher congestion level in the dest-opts than the actual ?
>> >
>> >/Ingemar
>> >
>> >=================================
>> >INGEMAR JOHANSSON  M.Sc.
>> >Senior Researcher
>> >
>> >Ericsson AB
>> >Wireless Access Networks
>> >Labratoriegränd 11
>> >971 28, Luleå, Sweden
>> >Phone [phone]
>> >SMS/MMS [phone]
>> >[e-mail]
>> >www.ericsson.com
>> >=================================
>> >_______________________________________________
>> >conex mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/conex
>>
>> __________________________________________________________
>> ______
>> Bob Briscoe,                                BT Innovate & Design
>>
>> _______________________________________________
>> conex mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/conex
> _______________________________________________
> conex mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/conex