archive mirror
 help / color / mirror / Atom feed
From: Xie He <>
To: David Laight <>
Cc: "David S. Miller" <>,
	Jakub Kicinski <>,
	"" <>,
	"" <>,
	"" <>,
	Martin Schiller <>
Subject: Re: [PATCH net-next] net: x25: Remove unimplemented X.25-over-LLC code stubs
Date: Thu, 10 Dec 2020 02:17:09 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Dec 10, 2020 at 1:14 AM David Laight <> wrote:
> > To me, LLC1 and LLC2 are to Ethernet what UDP and TCP are to IP
> > networks. I think we can use LLC1 and LLC2 wherever UDP and TCP can be
> > used, as long as we are in the same LAN and are willing to use MAC
> > addresses as the addresses.
> Except that you don't have any where near enough 'ports' so you need
> something to demultiplex messages to different applications.

Yes, LLC only has 256 "ports" compared to more than 60000 for UDP/TCP.

> We (ICL) always ran class 4 transport (which does error recovery)
> directly over LLC1 using MAC address (a NUL byte for the network layer).
> This requires a bridged network and globally unique MAC addresses.
> Sending out an LLC reflect packet to the broadcast MAC address used to
> generate a couple of thousand responses (many would get discarded
> because the bridges got overloaded).

Wow, You have a really big LAN!

> > X.25 layer 3 certainly can also run over LLC2.
> You don't need X.25 layer 3.
> X.25 layer 2 does error recovery over a point-to-point link.
> X.25 layer 3 does switching between machines.
> Class 2 transport does multiplexing over a reliable lower layer.
> So you normally need all three.

Yes, I was just saying X.25 layer 3 can run over any reliable
point-to-point links, including X.25 layer 2, LLC2 and TCP.

> However LLC2 gives you a reliable connection between two machines
> (selected by MAC address).
> So you should be able to run Class 2 transport (well one of its
> 4 variants!) directly over LL2.


> The advantage over Class 4 transport over LLC1 is that there is
> only one set of retransmit buffers (etc) regardless of the number
> of connections.

Right. But nowadays we have big enough memories for many buffers, so
it may be preferable to make connections operate independent of each
other. This way one lost frame wouldn't affect all connections. This
is also why HTTP3 moved to QUIC instead of using TCP.

> But this is all 30 year old history...

Haha, we are talking about really old technologies.

  reply	other threads:[~2020-12-10 10:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09  3:33 [PATCH net-next] net: x25: Remove unimplemented X.25-over-LLC code stubs Xie He
2020-12-09 21:21 ` David Laight
2020-12-09 22:53   ` Xie He
2020-12-10  9:14     ` David Laight
2020-12-10 10:17       ` Xie He [this message]
2020-12-10 22:34         ` David Laight
2020-12-13  1:20 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).