[e2e] Lost Layer?

[Detlef Bosau]

Am 11.02.2014 16:10, schrieb Joe Touch:
>
>
> On 2/11/2014 5:41 AM, Detlef Bosau wrote:
>> Am 11.02.2014 03:31, schrieb Joe Touch:
> ...
>>> I have no idea what a 'network' layer is that is different from what
>>> we currently call the link layer.
>>
>> And you are not the only one to have this problem.
>>
>> When you have a look at
>> @article{cerf,
>> title={ Protocol for Packet Network Intercommunication},
>> author={V.~ Cerf and R.~Kahn},
>> journal={IEEE Transactions on Communications},
>> month= "May",
>> year= "1974",
>> volume = "22",
>> number = "5",
>> pages = "637-- 648"
>> }
>
> At that time, the terminology was in flux.
>
> By the mid-1980s, it had settled as:
>
>     Internet        ISO
>
>     application layer    app, presentation, & session layers
>
>     transport layer        transport layer
>
>     Internet layer        network layer
>
>     subnetwork layer    link layer
>
> The other ISO layers were often buried inside the Internet's app
> layer, though they're now split out (e.g., for the web HTTP is a
> session layer, HTML a presentation layer, and the content the app layer).
>
> And we now (I hope) understand (or are starting to) that all the
> layers are really just relative to each other. All are just copies of
> the single step that wraps a lot of the ISO layers into a single
> function:
>
>
> layer (message, from-addr, to-addr) {
>     if (my-location == to-addr) then {
>         return
>     } else {
>         next-message = translate(message, nextlayer), i.e.,
>         translate the message to a format for the next layer,
>         including any/all of:
>             error correction
>             flow control
>             congestion control
>             data content translation
>             data format conversion
>             fragment/reassembly
>         translate this layer's identifiers to the next's:
>             next-from = lookup(from-addr, nextlayer);
>             next-to = lookup(to-addr, nextlayer);
>         recurse:
>             layer(next-message, next-from, next-to);
>     }
> } 

In a sense, you repeat e.g. congestion control throughout the layers,
hence congestion control may occur on every layer.

Where I do not agree is that you do both, flow control and congestion
control. I think this is THE basic misconception in internetworking that
these two were different. They aren't.

To my understanding, the term congestion control is meaningless. Period.
It tries to cover a conceptual design fault.
In a sense (the very sense of Simon & Garfunkel) it is "kodachrome".

May I refer to my favourite network technology, GPRS. A service time for
a 1024 byte packet in GPRS to be successfully delivered may
vary from 1 ms up to 6 minutes (= 600.000 ms).

So, in a setting

endpoint         GPRS link      endpoint

how many packets may be in transit?

One?

Or sixhundredthousand?

The "congestion control work" gives a precise answer here: CWND/packet
size. That's the precise number of packets, which may be in transit.

(I don't know the english word for this kind of ultraprecise numbers. In
German, we would say: "soundsoviele". There may be "soundsoviele"
packets in transit. And when you ask what "soundsoviele" means in
English, you ask the very question of TCP congestion control.)