RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]

On 21 Oct. 2017 10:28, "Lin Han" <Lin.Han@huawei.com> wrote:

-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Friday, October 20, 2017 12:00 PM
To: Lin Han <Lin.Han@huawei.com>; Brian E Carpenter <
brian.e.carpenter@gmail.com>
Cc: 6man WG <ipv6@ietf.org>
Subject: RE: Hop-by-hop [not draft-han-6man-in-band-
signaling-for-transport-qos-00.txt]

-----Original Message-----
From: Lin Han [mailto:Lin.Han@huawei.com]

> ATM is failed due to many reasons, scalability is one of it.
> This solution is not intended to replace completely the best-effort
> transport service. The solution is only for those application which
> really needs a flow level QoS, such as AR/VR, tactile internet, etc.
> From this sense, it does not sacrifice the scalability of IP.

Or at least, does not sacrifice it as much? ATM also had a UBR service.

[LH] Yeah, everything has cost. But it is still different, ATM UBR is
connection oriented, it needs setup and involves the control protocol such
as PNNI. In our case, the IP architecture is not touched at all. IP best
effort is as simple as before.

Not at all.

You're creating state in the forwarding plane. State created based on
traffic characteristics  is vulnerable to state exhaustion attacks.

Even in closed domains this can be an issue, because "closed" domains
attached to the Internet aren't guarateed to stay closed. Back in 2000
Nimbda caused a DoS on a router that I looked after in a closed domain that
was creating dynamic ACL entries for basic stateful firewalling.

RFC791 and RFC8200 forwarding is stateless.

I'd even say traffic created state is worse than connection oriented state
such as switched virtual circuits in ATM. In that model, hosts are
requesting permission to send traffic on the network before they're able to
- if the network can't set up a connection for a host, the host cannot
contribute traffic load to the network.

Stateless and stateful forwarding is the fundamental difference between
packet and circuit switched networks.

See 2.3 in RFC1958.

Regards,
Mark.

The new solution does not impact the IP routing or any other protocols.

But my point was only that out in the wild, you have no guarantee that the
routers in the path will know what to do with your in-band QoS demands.
Only in situations where all the routers are in your control will you have
that guarantee. But sure, in walled gardens, these cool ideas can be made
to work.
[LH] Agreed. But not that strict. As I said in the document, for
optimization, the HbH router is only needed for the point of the congestion
or device introducing a lot latency. It does not need all routers on the
path to be HbH aware. And if a router cannot guarantee the bandwidth, the
application can fall back to normal TCP, it does not completely disable the
transport.
The basic idea still works for multiple domain, I don't want to talk about
it since it may introduce more debating. Let see if there is any flaw for a
single domain. If it works, I'm sure technically we don't have problem to
apply to multiple domains.
One more infor for this domain issue. The network environment that an
application may need this QoS (ultra-high bandwidth and ultra-low latency)
may be flat, and very likely has a few domains (one or two). This is
because of the limit of propagation delay. For example, in the architecture
of 5G that is supposed to support the latency as low as single digit ms,
the content provider is supposed to connect to the SP's access network
directly and in the same metro. Only this deployment can provide the
physical distance as short as possible.

On the other hand, also in these controlled environments, another option,
frequently, is to "throw bandwidth at the problem." Give yourself plenty of
headroom. It's less elegant and less fun, but it works great.
[LH] not completely get what you mean

Bert

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------