Subject: Re: [conex] ConEx as sender side only modification

From: Bob Briscoe <[email-masked]>
Date: Thu, 29 Mar 2012 17:10:39 +0100

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 +46-1071 43042
>SMS/MMS +46-73 078 3289
>[email-masked]
>www.ericsson.com
>=================================
>_______________________________________________
>conex mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 30 Mar 2012 06:39:14 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bob Briscoe
> Sent: Donnerstag, 29. März 2012 18:11
> To: Ingemar Johansson S
> Cc: [email-masked]
> 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
> 
> >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.
> >modifications have been considered to make TCP echo back the exact
> >correct number of ECN-CE to the server.

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 30 Mar 2012 12:15:54 +0200

Hi

Thanks all, this really improved my understanding. 

/Ingemar

> From: Scheffenegger, Richard [mailto:[email-masked]] 
> Sent: den 30 mars 2012 08:39
> To: Bob Briscoe; Ingemar Johansson S
> Cc: [email-masked]
> Subject: RE: [conex] ConEx as sender side only modification
> 
> 
> 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
> 
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Bob Briscoe
> > 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
> > 
> > >client architecture as it is easier to modify a million 
> servers than 
> > >a zillion clients.
> > >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.

---

From: Matt Mathis <[email-masked]>
Date: Fri, 30 Mar 2012 21:52:06 +0200

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