Subject: Re: Flow Label consistency question

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 May 2005 12:36:23 +0200

Kit Plummer wrote:
> 
> On Apr 24, 2005, at 8:55 AM, Ran Liebermann wrote:
> 
>> Ofcourse if the label will also be used to classify traffic for
>> diffserv then this is one more reason for SPs to override the label to
>> zero on all ingress traffic from customers.
>>
> 
> If this is the case, and I hope it is...wouldn't is simply make more  
> sense for the SP to ignore the FL all together?  Therefore, if the FL  
> were pertinent on the other end...

The diffserv use case would use an e2e flow label to allow all diffserv
classifiers along the path to correctly reclassify the packet, even if
the protocol and port numbers are obscured by encryption. That only works
if the flow label value is preserved right up to the last router on the
last LAN on the path.

    Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Kit Plummer <[email-masked]>
Date: Tue, 3 May 2005 06:42:23 -0700

On May 3, 2005, at 3:36 AM, Brian E Carpenter wrote:

>> If this is the case, and I hope it is...wouldn't is simply make  
>> more  sense for the SP to ignore the FL all together?  Therefore,  
>> if the FL  were pertinent on the other end...
>>
>

Brian,

Just trying to see this straight...and I think I am understanding  
correctly.  But, my question is why would a SP override the label, if  
the label is to provide information from a classification  
perspective?  The answer as I see is that they shouldn't...and as you  
pointed out the necessity for preservation from true e2e.

Flow labeling is a very interesting topic to me/us.  Cool stuff.

Thanks.
Kit

------------------------------------------------------------------------
Kit Plummer
Operations Research and System Performance Dept.
Raytheon Missile Systems

---

From: Brian Haberman <[email-masked]>
Date: Tue, 3 May 2005 12:13:31 -0400

On May 3, 2005, at 9:42, Kit Plummer wrote:

>>>  sense for the SP to ignore the FL all together?  Therefore, if the 
>>> FL  were pertinent on the other end...
>>>
>>
> the label is to provide information from a classification perspective? 
>  The answer as I see is that they shouldn't...and as you pointed out 
> the necessity for preservation from true e2e.
>

I can't speak for Brian, but I understand what he is saying.  The FL is 
the
only end-to-end field used for classification.  The Traffic Class field 
will/
can be modified at the border of each service provider.  The FL remains
constant and can be input into that classification process.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 May 2005 17:41:13 +0200

Kit Plummer wrote:
>>> more  sense for the SP to ignore the FL all together?  Therefore,  if 
>>> the FL  were pertinent on the other end...
>>>
>>
> The answer as I see is that they shouldn't...and as you  pointed out the 
> necessity for preservation from true e2e.

The point is that (at the ISPs' request) the diffserv model allows
each ISP along the path to apply a different policy - so a packet
marked for EF treatment inside one ISP might be marked for AF
treatment inside another ISP. (You can argue that would be stupid, but
that's what the diffserv WG heard from the ISPs.) So different SPs will
interpret the same label differently.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 4 May 2005 10:43:35 +0100

> interpret the same label differently.

How weird :)

In the academic community, a lot of effort has been put in to agree some
common DSCP semantics; this has been particulary useful for LBE, where
end-to-end immutability of the DSCP is highly desirable (DSCP=8).  

If an ISP wants to apply local marking then it can, but one would hope
the value would be restored on exit from the ISP's scope.

I'm not aware of any research network that changes the value.

You can test this with the traceroute -t option to set a DSCP value, and
it'll report any change along the path.

I tried this to a US commercial server, and no DSCP change was reported.
WOuld be interesting to see who is seeing this happen in practice.

-- 
Tim/::1

---

From: "Eric Klein" <[email-masked]>
Date: Wed, 4 May 2005 12:39:18 +0300

Brian E Carpenter Wrote
> interpret the same label differently.

Do they change the original lable, or just apply diffrent policies on the
same lable?

If it is the first I can see many problems, but if it is the second I can
understand why they would want to control traffic transversing (or even
terminating) on their network diffrently than the originating network.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 4 May 2005 06:59:13 -0400

> Do they change the original lable, or just apply diffrent policies on 

The Flow Label is unaffected.  The Traffic Class field can be modified 
at
the ISP marking device.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 May 2005 14:54:13 +0200

>>interpret the same label differently.

The example I chose was deliberately weird to indicate the principle.
Perhaps a more realistic example is if ISP A marks VoIP traffic with
the EF code point, and ISP B marks it with Class Selector 5 (formerly
known as Precedence 5).

> end-to-end immutability of the DSCP is highly desirable (DSCP=8).  

Well, it wouldn't be needed if everyone agreed that all
sources would use Flow Label = 8 for all LBE flows, but different
domains chose to use (say) DSCP=0 or DSCP=8 for LBE traffic.

> the value would be restored on exit from the ISP's scope.

No, that's explicitly not a requirement in the diffserv architecture.
And it isn't algorthmically possible without adding a signalling
protocol - there are no 1:1 correspondences rules to invoke.
> WOuld be interesting to see who is seeing this happen in practice.

What I'm telling you is the way we were more or less told to design
diffserv by the operator community. For what people are now thinking,
see draft-ietf-tsvwg-diffserv-service-classes-00.txt.

Given this architecture, IPv6 has the advantage of the e2e Flow Label,
which IPv4 doesn't.

    Brian