gmane.network.end2end

Re: Port numbers in the network layer?

John Day — 2013-05-10T22:22:05

Boy, you are right about that!  It is *one* of the failures.  ;-)


No, I am conflating address with the homeomorphism used to create the 
address space.


No one suggested they did.   The peculiar thing about examples is 
that they are *examples* and represent only a single point in what 
could be a very large space.  They don't necessarily have all the 
properties of all the other examples from the same space.  Very 
peculiar.


Actually, this is incorrect.  All addresses support aggregation 
(given the previous definitions I used).  Although not all 
aggregations are useful for finding routes or establishing "physical 
nearness."


Absolutely.  An address is a type of name.  Nothing new there.  That 
has been well accepted as long as I have been around.

John

Re: Port numbers in the network layer?

Joe Touch — 2013-05-10T15:27:46

On May 8, 2013, at 1:45 PM, John Day <jeanjour< at >comcast.net> wrote:


Agreed; this, however, is one of the key failures of the "slice" model of network virtualization. It binds network interfaces and to OS components (slivers), and maps slivers to virtual networks. That inherently inhibits gateways - devices (or slivers) that bridge traffic between different VNs.


You're conflating "address" with a knowledge of the topology of its location space.

Location spaces need not be Euclidean or even continuous. Consider street addresses in Tokyo; two addresses on the same street typically satisfy no spatial "nearness" metric (the numbers are sometimes assigned in the order they are built, so 'near' is a temporal metric, rather than spatial).

And not all addresses support aggregation.

Finally, addresses *are* names. A "name" is just an identifier; once you assign meaning, it becomes something else - an endpoint identifier, a location identifier, etc. 

Joe

Re: Port numbers in the network layer?

John Day — 2013-05-08T20:45:33

Wasn't this obvious?    This is why they were called network 
"addresses" and not names.

The parallel was to OSs.  As Shoch put it, Application names indicate 
"what" and addresses indicate "where" and routes were "how to get 
there."  He didn't quite have the whole picture but close enough for 
this discussion.

Application names are suppose to be location-independent.  Except on 
broken OSs, you don't need to know what medium a file is on.

Addresses are suppose to be location-dependent, where given two 
addresses you should be able to tell if they are "near" each other 
for some definition of "near."  (not necessarily implying physical 
location, that while it can be useful is just the naive first 
thought.)  Although street addresses often have this property to 
varying degrees.  ;-)  Chicago more so than Boston!  ;-)

Although as I finally realized, application names are 
location-dependent too, just with a different meaning of "location."


At 2:52 PM -0400 5/8/13, Noel Chiappa wrote:

Re: Port numbers in the network layer?

Noel Chiappa — 2013-05-08T18:52:37

    > (especially due to the much later decision to conflate
    > endpoint-identifier with route that got made by default at BBN, perhaps
    > just to get the thing bootstrapped)

I see that differently...

The thing is that path selection, to scale, just has to have a namespace in
which things can be aggregated. (You just can't give everyone a complete map
of every last physical asset in the entire network.) IP _only had one
namespace available_. So, yeah, as the network grew it had to be organized in
a way that was aggregatable.

That started to happen early on, with subnets, although it didn't come into
full flower until later, with CIDR. Yes, the very early network did have
addresses that (at the 'network' level) were flat - but even then, hosts were
not free to move from network to network and keep their 'identity' - because
internet-wide path selection didn't (couldn't?) track individual hosts.

It was inevitable that that aggregation would ensue as the network got larger
- as a direct, and unavoida

Re: Port numbers in the network layer?

John Day — 2013-05-04T22:25:21

Thanks, Dave.  Those emails clarify a lot.

At 7:53 AM -0400 5/3/13, dpreed< at >reed.com wrote:

Re: Port numbers in the network layer?

John Day — 2013-05-02T23:42:05

Right.


Indeed, wireless can be point-to-point as well.


Excellent.


Alas, but you are right.  The constraints of software are 
sufficiently weak that unlike those of physics which are more 
constraining, it is still often possible to do it wrong.


"Deeply entrenched," indeed. (Some would say a synonym for 
tradition.) Strongly reasoned, less so.  As recently described by its 
author, it is this binding that thwarts mobility.

Indeed this "notion" exists in two different layers. In fact, it is a 
general property of all layers.  But I fail to see how that is an 
argument to require a pseudo-header.


It is far from distinct.  The two are tightly bound by header if 
nothing else.  Yes, most other protocols have not adopted that 
approach.  But the coupling between the two is very very loose.


I realize this is the definition, and I would even agree with 
including the same error-check-code, if they were in the same layer. 
But since it is said they aren't, I fail to see the need and I 
definitely see th

Re: Port numbers in the network layer?

Joe Touch — 2013-05-02T23:58:26

Hi, John,

On 5/2/2013 4:42 PM, John Day wrote:
...

It's an argument that it IS required in all current Internet transports. 
It is NOT an argument that it has to be required in a new transport 
protocol in the Internet, or in other new stacks.

...

A router should never do anything to the contents of an IP payload, IMO.

However, isn't that the definition of how a NAT works?

...

Yes, but when we're talking about existing protocols, the name is there. 
New protocols might use more accurate terms, just as IPv6 has a 
"hopcount" instead of a "TTL".

...

The destination port ID in a SYN encodes the service protocol, which is 
a protocol-type-id. It isn't an instance-id; the instance-id is the 
combination of the IP addresses and port numbers taken as a set.


Yes. Same for the destination port of the initial SYN in TCP.

...

Back at ya' ;-)

Joe

Re: Port numbers in the network layer?

Joe Touch — 2013-05-02T17:13:58

Hi, John,

On 5/2/2013 6:22 AM, John Day wrote:
...

Agreed; I mistyped; I meant "only if that point-to-point link".


Wireless includes point-to-point links, in which the information is 
either collimated (e.g., space-based laser links) or otherwise 
restricted within the link layer (e.g., CDMA).

But I think we now agree - connection ID is a connection demultiplexer 
within a context. It is required only if there is more than one 
connection to a given endpoint. An endpoint ID is an endpoint 
demultiplexer, and it is required only if there is more than one 
receiver on a link.


In order to stripe connections or shift them across links or endpoints 
within a link, a connection ID needs to be context-independent, i.e., 
unique across the potentially shared uses. That's a distinct feature of 
some, but not all, connection IDs.


The pseudoheader is an artifact of the TCP/IP split, which isn't as 
clean as often claimed.

It is used in other transport protocols built on IP, e.g., DCCP and SCTP.

It is not a m

Re: Port numbers in the network layer?

John Day — 2013-05-02T13:22:42

Sorry, I got a bit busy and then this got lost on my desktop.

At 8:27 PM -0700 4/28/13, Joe Touch wrote:

No, one does not need to go as far as multipoint links.  All that is 
needed are multiple applications trying to use the same media on a 
point-to-point link.  In that case, a connection-id or flow-id is 
required; however, addresses are not required.  It is true, that if 
it is a multi-drop or multi-point link, then addresses are required. 
Basically, addresses are necessary, if 'the wire" ;-) has more than 2 
ends! as wireless clearly does.


Not in the least, owing to the distinctions noted earlier in this 
thread, so-called striping and changing addresses are handled quite 
elegantly.


Actually not.  That is one of the more interesting aspects.

The argument for the pseudoheader has always been a bit shaky.  No 
other Transport Protocol except UDP either within or outside the IETF 
found the need for it.  There have been many discussions about 
removing it, but as you know tradition has always won

Re: flat (was Re: Port numbers in the network layer?

Joe Touch — 2013-04-29T22:00:22

The benefit of decoupling the service name from the destination port - 
in the current Internet - is an increased number of potential concurrent 
(or recently closed) connections.

That's described in the draft I posted earlier. The overhead need apply 
only to the first packet of a TCP connection.

Joe

On 4/28/2013 12:11 PM, Kevin Mason wrote:

Re: flat (was Re: Port numbers in the network layer?

Joe Touch — 2013-04-29T21:58:40

See http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt

Port numbers are still useful to demultiplex multiple connections to the 
same service, e.g., multiple concurrent HTTP sessions. But there's no 
reason to couple the destination demultiplexer with the service name.

Joe

On 4/26/2013 2:01 PM, christian.tschudin< at >unibas.ch wrote:

Re: Port numbers in the network layer?

Joe Touch — 2013-04-29T03:27:03


On 4/26/2013 9:11 PM, John Day wrote:

If you want to go that far off the map, connection-id would be needed 
only if that multipoint link supported different connections, either 
concurrently or in series.


Your definition implies that a connection ID differentiates connections 
only within one pair of source/destination addresses. That definition 
precludes connections that span multiple addresses, e.g., striping, or 
those that can shift addresses.


The TCP header includes the IP pseudoheader - notably for the purpose of 
connection identification. So TCP is already inconsistent with your 
proposed definition (it includes addresses in its connection ID, not 
merely as context for its connection ID), and consistent with the way I 
already described connections.


Transport layer ID that is based on a transport header that subsumes a 
subset of the network header.


Something has to listen in order for communication to proceed. That 
event need not precede the request to initiate from the other end, but

Re: flat (was Re: Port numbers in the network layer?

Kevin Mason — 2013-04-28T19:11:22

While interesting, what would be the absolute benefit?  The possibilities for confusion by mis-spelling alone would negate most of the gain.  Plus switching variable length, essentially random character socket indicators would be a huge overhead.

~Kevin


On Apr 26, 2013, at 5:01 PM, christian.tschudin< at >unibas.ch wrote:

Re: flat (was Re: Port numbers in the network layer?

Detlef Bosau — 2013-04-28T15:42:17

Am 26.04.2013 23:01, schrieb christian.tschudin< at >unibas.ch:

Hang on. Neither the past nor the future is the "reason".

A reason for doing something may be:
- a problem, I want to solve,
- a goal, I want to achieve.

Although I think, that I'm quite well educated in math, to me, CS in 
general and in particular networking, networking is an engineering 
science, not pure science. So we don't create more or less useful 
phantasies, which some person may hopefully find useful.

So, when we think about an architectural change (particularly a heavy 
weight change like moving port numbers to a different layer and hence 
changing encapsulations) we should give valid reasons for this.



O.k., I have to admit that I just listened to VJ's talk "A new way on to 
look at networking".

I presume VJ would lough at our discussion. While VJ tells us, we should 
"address" contents by name, we are nit picking about port numbers ;-)
(Even more important: E.g. Van's comments on security, which has simply 
a different view on th

Re: Port numbers in the network layer?

Detlef Bosau — 2013-04-27T15:27:22

Am 27.04.2013 00:30, schrieb John Day:

Watson's work is the delta-t protocol, right?

And your problem is that TCP is widely in use instead of delta-t, right?

Why is delta-t better than TCP?

Re: Port numbers in the network layer?

Detlef Bosau — 2013-04-27T15:24:24

Am 26.04.2013 21:39, schrieb John Day:


What is the difference?


In Germany, you could order an x.25 connection between site A and site 
B. I don't know whether this is still possible, but a few years ago, it was.

To my understanding, from the user's point of view, this was  a reliable 
character stream. Is this correct? Or do I miss something?

So, where is the precise difference to what I get, when I use a "Stream 
Socket" in Unix?

I'm just trying to figure out the system model used in the congavoid 
paper. That's why I'm interested in these things.

Re: Port numbers in the network layer?

John Day — 2013-04-27T04:11:52

I was speaking generally.  With point to point links, you can have 
multiple connections but no need for addresses.  But a connection-id 
is still necessary.

Strictly speaking, the proper way to define connection-id is the 
concatenation of the port-ids to form a connection-id that is unique 
within the scope of the pair of source/destination addresses.

Given that IP is in a different layer than TCP that would seem to be 
the definition that is consistent with that construction.

According to this socket pair definition then, is the connection id a 
Network Layer identifier or a Transport Layer identifier?


Do you mean the something has to be listening before the requesting 
application initiates the connection?  In that case, it is not true. 
It is possible to do and there are protocols operating today that do 
it.  Admittedly, they are not Internet protocols but that doesn't 
matter.


If you have a complete architecture handles all three phases of 
communication.  This is possible and has been demonst

Re: Port numbers in the network layer?

Joe Touch — 2013-04-27T00:42:52


On 4/26/2013 3:30 PM, John Day wrote:

In the Internet, the IP addresses are part of that connection ID, called 
the socket pair.


No protocol has a "means" to initiate connection with anything that 
isn't waiting for it on the other end. In this case, it would be an 
application listening on the socket. The assumption is both that the 
application is listening AND that the service (application protocol) is 
as expected.


You have to have agreement on the method for doing that. Otherwise 
you're assigning meaning to bit patterns arbitrarily or reading minds.


The portname is the name of the protocol and the application you expect 
to interpret it on the other end, just as a destination port is.

Yes, the resulting connections still use the current socket pair as the 
connection identifier, and yes, that still includes IP addresses. This 
was intended to be compatible with the existing Internet architecture, 
as noted therein.


That's the feature of such a version field.


I was clearly trying to extrap

Re: Port numbers in the network layer?

John Day — 2013-04-26T22:30:24

Problem?  What problem?  No one suggested there was a problem.

The question was about the distinction between protocol-id fields and 
port-ids.  I explained the difference and what the function of the 
protocol-id field was as opposed to the purpose of source and 
destination port-ids.  It is the case that the protocol-id field does 
have the rather disturbing property of requiring an (N)-protocol to 
have information about  (N+1)-protocols, while port-ids provide 
better isolation.

One of the implications of Watson's work is that port-id and 
connection-endpoint-ids should be distinct. This has a number of 
benefits.


For what value of "work"? ;-)

The current practice in TCP has certain security problems.  These 
stem from the fact that port-ids and connection-endpoint ids are 
conflated and the use of well-known ports.   The TCP server must rely 
on source port to distinguish connections to a well-known port.  This 
is a number it did not generate and can be spoofed and hence creates 
a security vulne

Re: Port numbers in the network layer?

John Day — 2013-04-26T22:30:11

The source and destination port-ids form a 
connection(flow)-identifier.  There had been experimentation with 
this in various protocols at the time.  Some had a single field, 
where the source numbered from one end and the destination from the 
other end hoping they would not meet in the middle.  The idea of 
simply concatenating locally unique identifiers became the common 
usage.


Actually, it does not identify the upper protocol or application, but 
a path to the upper protocol or application.  It is significant that 
this identified the type but there was no means (unless application 
specific) to establish communication with a particular instance of an 
application.

The use as a so-called well-known port was carried over from an early 
ARPANET shortcut.  This is equivalent to the early OS practice of 
reserving memory locations in low memory as jump points for 
applications.  OSs got beyond this. Networks never did.

As the reference above indicates there was consideration of names for 
applications

Re: Port numbers in the network layer?

John Day — 2013-04-26T19:39:12

X.25 does not provide the same reliability that TCP or TP4 does.

As Jon described, it is important to note that X.25 is an *interface* 
protocol in the ITU sense of interface.  It only specifies behavior 
between the DTE (host) and DCE (first router).  For some 
implementations (e.g. the French Transpac) this meant only that an 
ack meant that first DCE (router) got your packet; in Datapac (the 
Canadian offereing) an ack meant that the last DCE (router) got your 
packet; and in Telenet (the US offering), an ack meant that the 
remote host had acked the packet.  However, even with the Telenet 
interpretation, a Reset would cause the loss of packets that were not 
recovered.

At 9:27 PM +0200 4/26/13, Detlef Bosau wrote: