Re: [tsvwg] residential broadband BCP PHB and CP treatment Re: CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04

[<[e-mail]>]

[RG] marks my comments.

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[e-mail]] Im Auftrag von Mikael Abrahamsson
Gesendet: Samstag, 21. April 2018 07:46
An: Black, David <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] residential broadband BCP PHB and CP treatment Re: CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04

On Fri, 20 Apr 2018, Black, David wrote:

> IMHO, it's very important to distinguish this endpoint-marking use 
> case from the network interconnect use case.  For an example of 
> endpoint marking guidance, see (IESG-approved, but not yet published 
> as an RFC) draft-ietf-tsvwg-rtcweb-qos 
> (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/).  For 
> a network interconnect example, see RFC 8100.

       For me 8100 is not applicable. 8100 talks about interconnects set up and agreed on remapping, PHBs etc. What I am trying to create is "Internet default", which is the exact opposite. My document would be about what happens when there is no agreement and no prior knowledge, neither between end-customer and ISP, or between ISPs.

[RG] RFC8100 is about deployment of end-to-end PHBs in the presence of DSCP remarking. Do I get that correct, you propose end-to-end DSCPs to support local or endpoint PHB deployment? 

        However, draft-ietf-tsvwg-rtcweb-qos is highly applicable, as this speaks of what applications should do by default, and thus I want to try to make a proposal creating recommended Internet default (last-hop) PHBs that take this into account, but still also takes into account that anyone can source traffic into this so it shouldn't have strict priority for EF for example.

[RG] draft-ietf-tsvwg-rtcweb-qos is restricted to home-networks, residential networks and local wireless networks. It says "There are cases where these DSCP markings do not help, but, aside from possible priority inversion for "less than best effort traffic" (see Section 5), they seldom make things worse if packets are marked appropriately." And later " WebRTC use of multiple DSCP values may encounter network blocking of packets with certain DSCP values."
Are you suggesting any changes to that? 

[RG] Interestingly, DSCP 46 / EF is the one next to default which can almost be linked to end to end standard PHB and DSCP - if sender and receiver have a service agreement in place. That holds for Germany (public telephony, L3 VPNs, business and wholesale products, wireless and IP sections of wireline packet transport).

-- 
Mikael Abrahamsson    email: [e-mail]