[e2e] Is the end to end paradigm appropriate for congestion control?

[Emmanuel Lochin]

On 13/11/2013 12:18, Detlef Bosau wrote:
> Nevertheless, depending on the MAC scheme, in some cases no more than
> one packet may reside on the line. (On ring systems, of course, there
> may be several tokens/frames in flight.)
>
> However. As long as a receiver cannot accept the data, putting it on the
> line does not make any sense. (As in TCP: Flow control dominates
> congestion control.) More drastically spoken: The line capacity is of
> secondary interest, the primary interest is the next hop's capacity.
>
> Wouldn't it make sense to - at least experimental - consider a
> concatenated hop by hop flow control system?
>
> What would be the major problems in such a design?

Hi Detlef,

Such idea has already been proposed at the IETF'73 see 
http://www.brynosaurus.com/pub/net/logjam-slides-ietf73.pdf
and I found the meeting minutes here: 
*http://www.ietf.org/proceedings/73/minutes/tsvarea.txt*
It seems that this might introduce problem for secure communications in 
particular when using IPSec.

Emmanuel


>
> Detlef
>
>
> Am 12.11.2013 23:44, schrieb Richard Bennett:
>> The arithmetic on the size of bits on a network is pretty interesting.
>> At 1 Mpbs, a bit is 300m long, at 1 Gbps it's .3m, etc. So those old
>> ring systems never had more than one token circulating at a time, but
>> I saw 100 presentations that showed several in the network at the same
>> time.
>>
>> On 11/11/2013 11:19 PM, Jon Crowcroft wrote:
>>> and of course, any LAN tech has to start receiveing bits before you
>>> finish sending them....  (unless you choose the cambridge ring model
>>> with 16 bit minipackets - a precursor to atm)
>


-- 
Emmanuel Lochin
Professeur ISAE - OSSI
Institut Supérieur de l'Aéronautique et de l'Espace (ISAE)
Issu du rapprochement SUPAERO et ENSICA
10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4
Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88
Web : http://personnel.isae.fr/emmanuel-lochin/
---
"This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed"