Re: [conex] ConEx as sender side only modification

[Bob Briscoe <[e-mail]>]

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