Subject: [conex] Diag for draft-ietf-conex-concepts-uses

From: Bob Briscoe <[email-masked]>
Date: Fri, 24 Jun 2011 14:06:16 +0100

Folks,

Does this ASCII art float your boat?

I've introduced two big arrows containing congestion signals, so that 
it is clearer that the two forward congestion signals are in the same 
flows of packets, not separate flows.

Notice I've replaced 'Path' with 'Flow', so it is meant to represent 
the signals being carried within a flow of packets, rather than the 
path of nodes the flows traverse.

This is also a test of whether it remains readable using different 
client's renderings (different line spacings can break up diagonals 
made of forward and backslashes, but I've tested the two main 
spacings and they look OK).

Bob

    ,---------.                                               ,---------.
    |Transport|                                               |Transport|
    | Sender  |                                               |Receiver |
    |         |  /|___________________________________________|         |
    |     ,-<---------------Returned-Congestion-Signals--<--------.     |
    |     |   |/                                              |   |     |
    |     |   |\           Transport Layer Feedback Flow      |   |     |
    |     |   | \  ___________________________________________|   |     |
    |     |   |  \|                                           |   |     |
    |     |   |             ,-----------.                     |   |     |
    |     |   |_____________|           |______________|\     |   |     |
    |     |   |             |           |                \    |   |     |
    |     |   |  IP layer   |           | Data Flow       \   |   |     |
    |     |   |             |           |                  \  |   |     |
    |     |   |             |(Congested)|                   \ |   |     |
    |     |   |             |  Network  |                    \|   |     |
    |     |   |             |  Device   |                    /|   |     |
    |     |   |             |           |--Congestion-Signals--->-'     |
    |     |   |             |           |                  /  |         |
    |     `----------->--(new)-IP-layer-ConEx-Signals-------->|         |
    |         |_____________|           |______________  /    |         |
    |         |             |           |              |/     |         |
    `---------'             `-----------'                     `---------'

    Figure 1: Where the ConEx Protocol Fits in the Internet Architecture

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Michael Menth <[email-masked]>
Date: Fri, 24 Jun 2011 15:18:52 +0200

Hi Bob,

looks good to me, too. I like it.

Just one thing: the pillars say "transport sender/receiver"
This lets me think that information is exchanged on the transport layer. 
But in fact, conex info is carried on the IP layer while feedback 
information is carried on the transport layer.

This should be reflected somehow in the both pillars at the edges of the 
picture.

Best wishes,

     Michael

Am 24.06.2011 15:06, schrieb Bob Briscoe:
> made of forward and backslashes, but I've tested the two main spacings 
> and they look OK).
>
> Bob
>
>
>    ,---------.                                               ,---------.
>    |Transport|                                               |Transport|
>    | Sender  |                                               |Receiver |
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 24 Jun 2011 13:34:25 +0000

>But in fact, conex info is carried on the IP layer while feedback information is carried on the transport layer.

But the arrows in the diagram are labeled "IP layer Data Flow" and "Transport Layer Feedback Flow". Isn't that sufficient?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Friday, June 24, 2011 9:19 AM
To: Bob Briscoe
Cc: ConEx IETF list
Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses

Hi Bob,

Best wishes,

     Michael

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 24 Jun 2011 14:47:23 +0100

Michael,

I think I will leave it as transport sender/receiver.

This is an argument that could run and run. So I'd rather stop it 
now, as it is merely a question of definitions.

* Some would say that the transport receiver reads info from the IP 
layer and (with ConEx) the transport sender writes info into the IP layer.

* Some would say that the functions of drop, ECN marking and ConEx 
Policy are transport functions, so they say there is a rudimentary 
transport layer even on basic network equipment that only does 
tail-drop (e.g. John Day's "Patterns in Network Architecture; A 
Return to Fundamentals").

* Some would say the transport sender requests the IP sender to write 
into the IP header (which I think is your view).

* Yet another objection is that the application might implement these 
functions.

I have taken the view that Congestion Control and ConEx are 
transport-related functions.

Bob

At 14:18 24/06/2011, Michael Menth wrote:
>This lets me think that information is exchanged on the transport 
>layer. But in fact, conex info is carried on the IP layer while 
>feedback information is carried on the transport layer.
>
>This should be reflected somehow in the both pillars at the edges of 
>the picture.
>
>Best wishes,
>
>     Michael
>
>
>
>>I've introduced two big arrows containing congestion signals, so 
>>that it is clearer that the two forward congestion signals are in 
>>the same flows of packets, not separate flows.
>>
>>Notice I've replaced 'Path' with 'Flow', so it is meant to 
>>represent the signals being carried within a flow of packets, 
>>rather than the path of nodes the flows traverse.
>>

---

From: Michael Menth <[email-masked]>
Date: Fri, 24 Jun 2011 16:08:39 +0200

Hi Bob,

I'm not debating the transport aspect, this is there for sure, too. 
However, we want to implement conex in IP because every node on the path 
should be able to see the conex information. Or is this assumption no 
longer valid? And this should be reflected, otherwise the picture may be 
misleading.

Regards,

     Michael

Am 24.06.2011 15:47, schrieb Bob Briscoe:
> This is an argument that could run and run. So I'd rather stop it now, 
> as it is merely a question of definitions.
>
> tail-drop (e.g. John Day's "Patterns in Network Architecture; A Return 
> to Fundamentals").
>
>>>    ,---------.                                               
>>> ,---------.
>>>    |Transport|                                               
>>> |Transport|
>>>    | Sender  |                                               
>>> |Receiver |
>>>    |         |  
>>> /|___________________________________________|         |
>>>    |     
>>> ,-<---------------Returned-Congestion-Signals--<--------.     |
>>>    |     |   |/                                              |   
>>> |     |
>>>    |     |   |  \|                                           |   
>>> |     |
>>>    |     |   |             ,-----------.                     |   
>>> |     |
>>>    |     |   |             |           |                \    |   
>>> |     |
>>>    |     |   |             |           |                  \  |   
>>> |     |
>>>    |     |   |             |  Network  |                    \|   
>>> |     |
>>>    |     |   |             |  Device   |                    /|   
>>> |     |
>>>    |     |   |             |           |                  /  
>>> |         |
>>>    |     
>>> `----------->--(new)-IP-layer-ConEx-Signals-------->|         |
>>>    |         |             |           |              |/     
>>> |         |

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Jun 2011 11:27:34 -0400

This is a big improvement. The only thing which jumps out at me is
the reader asking, "How is a Transport Sender different from any other
kind of Sender?"

   However, there is the occupational hazard of becoming so familiar
with a diagram that we can no longer see it with fresh eyes. I'd like
to see some explanatory text near the diagram -- though I don't at
first blush see any absolute need...

--
John Leslie <[email-masked]>

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 24 Jun 2011 16:41:48 +0100

John,

Thanks - we have some progress.

To an Ethernet person, a sender is an IP router.
To an MPLS person, a sender can be an IP router.

Transport sender means a sender with a transport layer on it. It 
could be the source, a Web proxy, a TCP proxy, or a router sending on 
a SCTP connection to a management system.

Bob

---

From: Michael Menth <[email-masked]>
Date: Fri, 24 Jun 2011 17:46:22 +0200

Hi Bob,

Am 24.06.2011 17:41, schrieb Bob Briscoe:
> Transport sender means a sender with a transport layer on it. It could 
> be the source, a Web proxy, a TCP proxy, or a router sending on a SCTP 
> connection to a management system.
This is the missing explanation. You mean that the sender and receiver 
must have some transport layer capability. That's ok, but must be 
explicitly stated in the accompanying text. I got it wrong.

Regards,

     Michael

---

From: "Toby Moncaster" <[email-masked]>
Date: Sat, 25 Jun 2011 21:31:02 +0100

I agree with Michael (and John) - the diagram is good (and pretty impressive
for ASCII art), but you need to make sure you explain what is meant by
transport tx/rx as the term could confuse folks. It should be easy enough to
incorporate the explanation in the text near the diagram...

Toby

> Sent: 24 June 2011 16:46
> could

---

From: Michael Menth <[email-masked]>
Date: Sat, 25 Jun 2011 23:31:12 +0200

> But the arrows in the diagram are labeled "IP layer Data Flow" and "Transport Layer Feedback Flow". Isn't that sufficient?
That's not the problem. It's not clear why it is necessary to mention 
that the endpoints are transport sender/receiver. If it is important, 
then explain briefly in the accompanying text, if it is not important, 
then drop the label! Probably you mean that the sender must be a 
transport endpoint to find out about congestion from the receiver and 
then conex-marks packets on the IP-layer. Something along these lines 
should be said in the text. Then it's clear what the "transport 
sender/receiver" labels mean.

Regards,

     Michael

>> Bob Briscoe,                                BT Innovate&  Design

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 25 Jun 2011 08:53:59 +0100

Michael,

'Transport sender/receiver is used widely in IETF documents. I would 
rather not disrupt the flow of the introduction to define every word 
and phrase.

When anyone first comes across these two words together, surely the 
only possible meaning is the sender or receiver at the transport 
layer. Your concern was different: that the ConEx protocol appears at 
the IP layer. This is not a problem because higher layers always 
determine what appears on the wire at lower layers. That's how 
everything always works. We cannot include a whole book's worth of 
text about general Internet architecture within a document on ConEx.

Bob

At 16:46 24/06/2011, Michael Menth wrote:
>>could be the source, a Web proxy, a TCP proxy, or a router sending 
>>on a SCTP connection to a management system.
>This is the missing explanation. You mean that the sender and 
>receiver must have some transport layer capability. That's ok, but 
>must be explicitly stated in the accompanying text. I got it wrong.
>
>Regards,
>
>     Michael
>
>
>>
>>
>>Bob
>>