Re: [conex] ConEx as sender side only modification

[Ingemar Johansson S <[e-mail]>]

Hi

Thanks all, this really improved my understanding. 

/Ingemar

> -----Original Message-----
> From: Scheffenegger, Richard [mailto:[e-mail]] 
> Sent: den 30 mars 2012 08:39
> To: Bob Briscoe; Ingemar Johansson S
> Cc: [e-mail]
> 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
> 
> 
> > -----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
>