Subject: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 13 Aug 2014 21:33:06 +0100

I can see good points raised on the details, instead I have some 
questions about the overall document strcuture:

(1) This statement appears at the end of section 2:

    "Multiplexing may reduce the complexity and resulting load on an
    endpoint.  A single instance of STUN/ICE/TURN is simpler to execute
    and manage than multiple instances STUN/ICE/TURN operations happening
    in parallel, as the latter require synchronization and create more
    complex failure situations that have to be cleaned up by additional
    code."

I suspect this is all true, but I'd like to ask that section 4 also 
makes a similar summary claim at the end - saying that using a single 5 
tuple and multiplexing multiple streams with *different* QoS expectation 
and therefore different DSCP markings can complicate the transport 
protocol design, by requiring a transport to disambiguate the congestion 
state for each network QoS category that is used. It will also result in 
increased complexity at the transport layer to validate path integrity, 
where a 5-tuple could result in a different routing/forwarding path in 
order to validate that the individual 5-tuples are reachable.  Of 
course, using DSCPs with an AF class can reduce some of the latter 
costs. etc according to what the draft says.

I don't suggest that the extra complexity and additional algorithms are 
as big a problem as being unable to get through a NAPT/Firewall, but it 
seems that this nonetheless extra stuff that I don't recall having been 
worked upon before in the IETF - and a challenge I guess for the RMCAT WG.

(2) I don't know if the document's goal is also to make transport 
recommendations for using multiple code points - i.e.things such as 
must be robust to the network changing a DSCP; needs to independently 
verify that a particular DCSP is not being black-holed, needs to not 
imply relative precedence when interpreting loss or marking of packets 
for a flow using multiple DCSPs etc. ???

If these are out of scope, then maybe the document should say that this 
particular document does not provide this sort of guidance.

Gorry

---

From: <[email-masked]>
Date: Thu, 14 Aug 2014 14:08:00 +0200

Hi Gorry,

the following text will likely appear in the next version of my diffserv-intercon draft. The more DSCPs appear in a flow which aren't deployed end-to-end for the corresponding PHB, the more often one of the scenarios will be encountered.

The following scenarios start from a domain sending 
IP traffic using a PHB and a corresponding DSCP to an interconnected 
domain. The receiving domain may
-	Support the PHB and offer the same corresponding DSCP
-	Not support the PHB and use the DSCP for a different PHB
-	Not support the PHB and not use the DSCP
-	Support the PHB with a differing DSCP, and the DSCP of the
       sending domain is not used for another PHB
-	Support the PHB with a differing DSCP, and the DSCP of the
       sending domain is used for another PHB

Another question to be answered then is how a network provider will treat unrecognized or unexpected DSCPs received at network boundaries.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Dart [mailto:[email-masked]] Im Auftrag von Gorry Fairhurst
Gesendet: Mittwoch, 13. August 2014 22:33
An: [email-masked]
Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02

I can see good points raised on the details, instead I have some questions about the overall document strcuture:

[snip]

(2) I don't know if the document's goal is also to make transport recommendations for using multiple code points - i.e.things such as must be robust to the network changing a DSCP; needs to independently verify that a particular DCSP is not being black-holed, needs to not imply relative precedence when interpreting loss or marking of packets for a flow using multiple DCSPs etc. ???

If these are out of scope, then maybe the document should say that this particular document does not provide this sort of guidance.

Gorry

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

---

From: [email-masked]
Date: Thu, 14 Aug 2014 14:05:36 +0100

Thanks

When I said "transport" I was thinking of the algorithms to be used in the
end-host to figure out what was operational and where congestion and delay
were experienced. But what you say is all an import part. I expect what
you discuss, could go into the tsvwg intercom draft.

Gorry
> Hi Gorry,
>
> the following text will likely appear in the next version of my
> diffserv-intercon draft. The more DSCPs appear in a flow which aren't
> deployed end-to-end for the corresponding PHB, the more often one of the
> scenarios will be encountered.
>
> Another question to be answered then is how a network provider will treat
> unrecognized or unexpected DSCPs received at network boundaries.
>
> Regards,
>
> Ruediger
>
>
> recommendations for using multiple code points - i.e.things such as must
> be robust to the network changing a DSCP; needs to independently verify
> that a particular DCSP is not being black-holed, needs to not imply
> relative precedence when interpreting loss or marking of packets for a
> flow using multiple DCSPs etc. ???
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Aug 2014 07:58:08 +1200

> Another question to be answered then is how a network provider will treat unrecognized or unexpected DSCPs received at network boundaries.

Quoting RFC 2475:

  "A DS domain has a well-defined boundary consisting of
   DS boundary nodes which classify and possibly condition ingress
   traffic to ensure that packets which transit the domain are
   appropriately marked to select a PHB from one of the PHB groups
   supported within the domain."

In other words the assumption is that (unless there's an SLA
that allows the receiving domain to trust the incoming DSCP),
a classifier is needed. My assumption has always been that
the default classifier will simply re-mark packets with the
default DSCP.

We also have
  "A DS ingress node is responsible for ensuring that the traffic entering
   the DS domain conforms to any TCA between it and the other domain to
   which the ingress node is connected."

and the definition of a TCA:

"  Traffic Conditioning      an agreement specifying classifier rules
   Agreement (TCA)           and any corresponding traffic profiles and
                             metering, marking, discarding and/or
                             shaping rules which are to apply to the
                             traffic streams selected by the classifier.
                             A TCA encompasses all of the traffic
                             conditioning rules explicitly specified
                             within a SLA along with all of the rules
                             implicit from the relevant service
                             requirements and/or from a DS domain's
                             service provisioning policy."

In other words: the treatment of unrecognized DSCPs needs to
be stated in the TCA part of the SLA.

Of course you could suggest a default approach in diffserv-intercon.

    Brian

---

From: <[email-masked]>
Date: Fri, 15 Aug 2014 07:08:31 +0200

Hi Brian,

standards agree on the PHB which unrecognised DSCPs should receive, which is 
default forwarding. RFC2474 however proposes to transport the DSCP without 
remarking: 

   Packets received with an unrecognized codepoint SHOULD be forwarded
   as if they were marked for the Default behavior (see Sec. 4), and
   their codepoints should not be changed.  Such packets MUST NOT cause
   the network node to malfunction.

The MUST NOT cause malfunction clause leaves a way out and I personally 
favor rewrite to default DSCP.

There has been a discussion whether a rewrite of several incoming DSCP 
to a single outgoing DSCP is DiffServ compatible or not. Here we have 
such a rewrite. It seems to be alright for not supported DSCPs and PHBs.

As you mention, a TCA/SLA stating treatment of all DSCPs is important 
at network domain boundaries.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Dart [mailto:[email-masked]] Im Auftrag von Brian E Carpenter
Gesendet: Donnerstag, 14. August 2014 21:58
An: Geib, Rüdiger
Cc: [email-masked]; [email-masked]
Betreff: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02

Quoting RFC 2475:

In other words the assumption is that (unless there's an SLA that allows the receiving domain to trust the incoming DSCP), a classifier is needed. My assumption has always been that the default classifier will simply re-mark packets with the default DSCP.

We also have

In other words: the treatment of unrecognized DSCPs needs to be stated in the TCA part of the SLA.

    Brian