Subject: Re: [Detnet] Your comment on 5 tuple vs 6 tuple flow identification

From: "Black, David" <[email-masked]>
Date: Thu, 8 Nov 2018 07:45:10 +0000

Lou Berger writes:

>      I paraphrased my understanding of your comment on 5-tuple vs
> 6-tuple as that 5 tuple can be used for next hop selection, but 6-tuple
> (5+DSCP) should only be used for different traffic treatment.  Assuming
> this is correct, you're basically saying that a single 5-tuple flow
> should never be sent over a different path through a network.  Is this a
> correct interpretation of your comments?
> 
> If so, how do you see Multi-topology (RFCs 4915, 5120, 7722) routing
> conforming/meeting this requirement?

In practice, I'd generally expect network operators to configure topology
selection so that each 5-tuple flow uses a single topology.   Spreading a
5-tuple flow across multiple topologies is likely to lead to packet reordering
that can cause negative effects on some transport protocols and applications.

In general, see the discussion of Transport Protocols and Reordering in
Section 5.1 of RFC 7657, which deals with reordering that arises from a
different cause: https://tools.ietf.org/html/rfc7657#section-5.1.

Thanks,
--David

---

From: Lou Berger <[email-masked]>
Date: Thu, 8 Nov 2018 14:22:51 +0700

Hi David,

Thanks,

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 8 Nov 2018 15:05:09 +0700

> that can cause negative effects on some transport protocols and applications.

While I don't disagree that this is reasonable, it isn't what is 
supported by the MTR RFCs I reference above.  Given those RFCs (and real 
deployments) don't preclude nexthop selection based on DSCP in this 
document, i.e., at the architectural level.  Note that I'm limiting this 
comment to the architecture draft -- I'm not changing my view on what 
should be documented in the ip solution draft, i.e., what was summarized 
in the IP related thread on the DetNet list.

Thanks,

Lou

> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: "Black, David" <[email-masked]>
Date: Thu, 8 Nov 2018 15:06:31 +0000

Lou,

I think that there are two subtly different concepts here:

>> you're basically saying that a single 5-tuple flow
>> should never be sent over a different path through a network.

I think that overstates what I said, but it's also not the same concept as: 

>>  Given those RFCs (and real
>> document, i.e., at the architectural level.

Nexthop selection based on DSCP seems ok.  Senders are supposed to mark
flows, at least for reliable delivery transport protocols, with only one or
a consistent set of DSCPs is used that won't cause reordering (for more on
this see RFC 7657).

Web RTC mixes a bunch of different types and priorities of traffic onto a
single 5-tuple, and can use a variety of DSCPs for it - see
draft-ietf-tsvwg-rtcweb-qos.  If one uses DSCP for next hop selection,
that would result in different paths for different types & priorities of traffic,
which could result in extensive reordering.  That's ok, as the Web RTC
receiver is not expecting ordered delivery outside of a single [type, priority]
traffic subset.

>  Note that I'm limiting this

I think we're agreeing, but I'm not sure why the architecture draft is part
of this discussion thread.  My 5-tuple vs. 6-tuple comment at the microphone
was in the context of promising to carefully write some text for clarity in
this area of the IP solution draft. 

Thanks, --David

> -----Original Message-----
> From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Thursday, November 8, 2018 3:05 AM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [Detnet] Your comment on 5 tuple vs 6 tuple flow identification
> 
> 
> [EXTERNAL EMAIL]
> Please report any suspicious attachments, links, or requests for sensitive
> information.
> 
> 
>

---

From: Norman Finn <[email-masked]>
Date: Fri, 9 Nov 2018 02:11:48 +0000

I rather like David's "flow = 5-tuple, QoS = 6-tuple".

It may be that there are RFCs that permit the DCSP to influence the choice of output interface, but I definitely don't want DetNet to require or assume this capability.

FWIW, IEEE 802 is very strict about that; L2 priority does not influence forwarding -- only QoS.

-- Norm

________________________________________
From: detnet [[email-masked]] on behalf of Black, David [[email-masked]]
Sent: Thursday, November 08, 2018 7:06 AM
To: Lou Berger
Cc: [email-masked]
Subject: Re: [Detnet] Your comment on 5 tuple vs 6 tuple flow identification

Lou,

Thanks, --David

---

From: "Black, David" <[email-masked]>
Date: Fri, 9 Nov 2018 03:52:33 +0000

And to complete the Web RTC story - to a first approximation, what's going on there is that independent flows at the application layer that would be on separate 5-tuples (and different DSCPs) are being multiplexed onto a single 5-tuple in order to more effectively do battle with NATs.  That raises the question of whether the IP solution needs to support this sort of flow multiplexing - in private discussion, Lou has advocated that this functionality is important.

Thanks, --David

> From: Norman Finn [mailto:[email-masked]]
> Sent: Thursday, November 8, 2018 9:12 PM
> To: Black, David; Lou Berger
> Cc: [email-masked]
> Subject: RE: [Detnet] Your comment on 5 tuple vs 6 tuple flow identification
> 
> 
> [EXTERNAL EMAIL]
> It may be that there are RFCs that permit the DCSP to influence the choice of
> output interface, but I definitely don't want DetNet to require or assume this
> capability.
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 9 Nov 2018 11:36:39 +0700

Hi David,

> a consistent set of DSCPs is used that won't cause reordering (for more on

I think this works in practice in environments where there is remarking 
based on 5-tuple.  I'm less sure (and have less experience with) of the 
case where end applications are doing marking within the same 5-tuple, 
but certainly know that such is allowed and may be useful to certain 
DetNet applications.

> this area of the IP solution draft.

Fair enough, I think I misinterpreted your statements as architectural 
restrictions vs a practical one.  Keeping in mind that we've been 
informally calling this the 'simplified IP' solution,  adding reasonable 
restrictions in the solution draft sounds fine to me.  (with any hat)

Lou

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 15 Nov 2018 03:06:18 +0100

> I rather like David's "flow = 5-tuple, QoS = 6-tuple".

Btw: I was saying exactly the same thing at the mike @IETF101 but the
that just ended up in a long debate that resultet AFAIK in no change in
the documents.

IMHO, It would really help to avoid a lot of future
misdesigns if DSCP was clearly not prt of the DetNet IP flow
identification, but just defining QoS, and depending on what
QoS mechanism is used it could be one or multiple values.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 15 Nov 2018 03:35:24 +0100

At the end...

On Thu, Nov 08, 2018 at 02:22:51PM +0700, Lou Berger wrote:
> Hi David,
> 
>     I paraphrased my understanding of your comment on 5-tuple vs 6-tuple as
> that 5 tuple can be used for next hop selection, but 6-tuple (5+DSCP) should
> only be used for different traffic treatment.  Assuming this is correct,
> you're basically saying that a single 5-tuple flow should never be sent over
> a different path through a network.  Is this a correct interpretation of
> your comments?
> 

Lou

In my memory, the investment into DSCP based MTR for IP unicast was a
desaster for the vendors because customers first thought it was a good
idea, it got implemented, and then customers figured 'oh wait, i need
QoS and MTR, but overloading a sinle selector make it really
unmanageable". And i had problems avoiding for the MTR routing code to
become unsupported in products because it was still valuable for
IP multicsat, even with two topologies to do dual-transmission solutions
(with PREF being mostly done by endpoints, only little of that managed
to go into routers unfortunately... Hence the interest in DetNet to
bring more PREF into routers ;-)

In any case, i have posted the following to LSR to figure out what
the rough consensus for DSCP with MTR could be, lets see if my
understanding is right or not.

Cheers
    Toerless

From: Toerless Eckert <[email-masked]>
To: [email-masked]
Subject: LSR: Using DSCP for path/topology selection Q
Message-ID: <[email-masked]>

Whats the current best guidance on using DSCP for selection of path,
specifically for selection of topology with MTR (RFCs 4915, 5120, 7722) ?

My understanding from history is that this looked like a good idea
to customers first, but when implementations became available,
customers really did not want to implement it because of the overloading
of DSCP between QoS and routing and the resulting management complexity.

Has the idea of using DSCP for path selection been re-introduced in any
later work like flex-Algos ?

If there could be rough consensus that this is in general a bad idea, i wonder
if it would be appropriate to have a short normative document from LSR
defining that the use of DSCP for topology selection is historic and
not recommended anymore and make this an update to above three RFCs,
maybe also pointing out that there are other methods to select a
topology and those remain viable:

I specifically would not like to see the actual MTR RFCs to be changed
in status, because MTR actually does work quite well and is supported
in products and deployed with IP multicast, even with multiple
topologies for IP multicast in live-live scenarios. 

Thanks!
    Toerless