Phillip,
> Since most DSCP and QoS functions are normally handled within a single
> network domain, what impact would it have to manually set precedence at the
> edge.
>
> for example,
> CE = customer edge, or host systems (TCP endpoints)
> PE = Provider edge,
> P = Provider Core,
>
> CE - PE - P - PE - CE
I'll modify as:
CE1 -- PE1 -- P -- PE2 -- CE2
>
> If the provider PE edge manually sets the precedence outbound to the CE what
> affect will this have on the TCP session.
As I think you know, the primary catalyst for this modification
was observed operational behaviour. We saw that when mid-point
devices [P] changed TOS/DSCP and the observed response packets
[at CE1] within the TCP session varied, CE1 would reset the packet.
> the TCP RST condition should happen when their is a ["lower precedence" or
> any change in precedence] if both ends where set to the same precedence by
> the PE router
Although a viable solution, this is difficult to implement in
practice. The need this presents for PE1 and PE2 to synchronize by
session and policy is great. I believe this demand would severely
impede DHCP/TOS and internet deployment.
Another implementation workaround would maintain state as below,
but this is only a partial resolution to the problem.
> for example precedence or dscp of "0". Does tcp security have
> a specific requirement of precedence,
In practice, no. Per a strict interpretation of the RFC793, yes.
We saw that mainly some [10%] of MacTCP (apple) TCP/IP stacks
enforced this, as well as some old IBM stacks.
> what happens if the tcp stack
> initiates a connection with a precedence of 1 and during transmission it
> gets reassigned with precedence of "0" does this screw the TCP
> session/connection?
Yes, because what CE1 sends "1" is changed by {PE1,P,PE2, or CE2}
and is not what he expected.
> is manually setting precedence or DSCP to the a single
> value outbound to the CE or TCP endpoints a possible work around?
It might be, except that it either:
requires sychnornization by CE's or PE's
or
disallows tcp-based DSCP delivery. One could set things to a
default value [say, 0] and remember what it got on a
flow-by-flow basis. However, this would negate end-to-end
ability of DSCP/TCP; which is certainly a desirable behaviour
we do not wish to negate.
-alan
>
> Regards
> Phillip.
>
> ********************************************
> Phillip Grasso-Nguyen (CCNA)
> Senior Network Engineer - Core Engineering Team
> Davnet Telecommunications
> Level 7, Magna Data House
> 209 Castlereagh Street, Sydney
> NSW, Australia, 2000.
> Tel: +61 2 9272 9600 Fax: +61 2 9272 9605
> mailto:[EMAIL PROTECTED]
> http://www.magna.com.au
> PGP Fingerprint:1083 7987 D33A C7E8 5DB2 AAD2 4F5D 6B99 CBB7 55A4
> PGP Key: http://www.magna.com.au/~phillipg/phillipg.asc
> Australian General Telecommunications Carrier License No 23
> ********************************************
> Disclaimer: http://www.magna.com.au/~phillipg/disclaimer.txt
> "Leave complexity at the 'edges' and keep the network 'core' simple"
