Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 10 Apr 2006 16:19:03 -0400

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Monday, April 10, 2006 12:45 PM
> To: 'Patrick Melampy'; [email-masked]
> Subject: RE: [Speermint]
RE:BackgroundReadingonNGNInterconnect-transitvs
> peering
> 
> I personally think this is way over the top for a BCP.
> 
> If such things were deployed now, even experimentally, and we had some
> good
> reports on complexity, stability and usefulness, then maybe we could
> document that as "Best Current Practice".  In the absence of anything
like
> it, to my knowledge, in the wild, I'd say let's not go there.
> 
> I'm pretty certain that an objective evaluation of this scheme would
> result
> in a "more bandwidth is cheaper" conclusion, but since my speculation
> isn't
> any more valid that yours I think we just fagetabodit.
> 
> Can we just stick with per T-domain marking and DiffServ?
[[Reinaldo]] 

I think this will not meet the needs to of (V)ISPs. We are talking about
_multimedia_ peering, so we should at least have something similar to:

    ------------------------------------------------------------------
   |   Service     |  DSCP   |    DSCP     |       Application        |
   |  Class name   |  name   |    value    |        Examples          |
   |===============+=========+=============+==========================|
   | Telephony     |   EF    |   101110    | IP Telephony bearer      |
   |---------------+---------+-------------+--------------------------|
   |  Signaling    |  CS5    |   101000    | IP Telephony signaling   |
   |---------------+---------+-------------+--------------------------|
   | Multimedia    |AF41,AF42|100010,100100|   H.323/V2 video         |
   | Conferencing  |  AF43   |   100110    |  conferencing (adaptive) |
   |---------------+---------+-------------+--------------------------|
   |  Real-time    |  CS4    |   100000    | Video conferencing and   |
   |  Interactive  |         |             | Interactive gaming       |
   |---------------+---------+-------------+--------------------------|
   | Multimedia    |AF31,AF32|011010,011100| Streaming video and      |
   | Streaming     |  AF33   |   011110    |   audio on demand        |
   |---------------+---------+-------------+--------------------------|
   |Broadcast Video|  CS3    |   011000    |Broadcast TV & live events|
   |---------------+---------+-------------+--------------------------|

Of course that does not preclude somebody from marking on a per flow
basis.

Regards,

Reinaldo

> 
> Brian
> 
> -----Original Message-----
> From: Patrick Melampy [mailto:[email-masked]]
> Sent: Saturday, April 08, 2006 10:53 AM
> To: [email-masked]
> Subject: RE: [Speermint] RE:
BackgroundReadingonNGNInterconnect-transitvs
> peering
> 
> 
> Brian,
> 
> This new kind of policy driven marking thing must work across network
> borders -- and across trust boundaries. What we really need to solve
the
> routing problem is a second forwarding equivalence class -- one for
best
> efforts, and one for voice. These must be advertised through BGP4
edges to
> effect a second routing plane. Only then can you solve the routing
> problem.
> 
> If this was all completed, and we could make packets route differently
> based
> on service (different next-hop networks), we have solved a first
problem.
> However it is unclear that we have made the internet better. Now when
you
> "ping" an address, you get a different response if the ToS is best
efforts
> verses Voice. You also would have to revise ICMP handling to deal with
> "unreachable address messages" to take into account the ToS. There may
be
> many other protocol issues that occur when these bits are not set
> properly.
> 
> I can think of one simple one.
> 
> I want to establish a TCP/TLS SIPS session to a proxy. This proxy is
ONLY
> reachable in the ToS Voice forwarding plane. However, when I use the
> Berkely
> Sockets to create the socket ... the syn/syn syn/ack ack three way
> handshake
> doesn't have the ToS bits set yet (since I can't do a SOCKOPTS until
the
> socket is opened). Thus we would have to alter the ways Berkely
sockets
> work
> to ensure that the 3way TCP handshake routes properly.
> 
> These complications may be worth the salvation of honor and avoidance
of
> doing something evil like a simple NAT like SBC's do.
> 
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 3:03 PM
> To: 'Michael Hammer (mhammer)'; [email-masked]
> Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background
> ReadingonNGNInterconnect-transitvs peering
> 
> Uh-huh, at least for a generic "everyone should do this" kind of
thing.
> 
> I have no illusions that big complex carrier networks will adopt
anything
> as
> straightforward as -service-classes, but many more focused carriers
could,
> and profit there-by.
> 
> So, I think our BCP should reference that work, but I believe it's not
> sufficient.  We probably need some kind of policy driven re-marking
> thingy.
> 
> What I'm not so sure about is PER FLOW decision making.  PER
"T-NETWORK"
> is
> maybe doable.
> 
> Brian
> 
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 2:55 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background
> Reading
> onNGNInterconnect-transitvs peering
> 
> Brian,
> 
> Are you talking something like?:
> draft-ietf-tsvwg-diffserv-service-classes-02.txt
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Friday, April 07, 2006 1:44 PM
> > To: [email-masked]
> > Subject: RE: Media Packet Marking,was RE: [Speermint] RE:
> > Background Reading onNGNInterconnect-transitvs peering
> >
> >
> > I changed the subject line, at least this part of the thread may be
> > fruitful>
> >
> >
> > >>This doesn't say you can't have VPN tunnels, or MPLS
> > tunnels, or any
> > >>other kind of links down in the router.
> > >
> > >The process of getting signaled RTP data onto these tunnels, and
not
> > >the best efforts packets from the same IP address pairs, is
> > essential
> > >and in scope.
> >
> > ....
> >
> > >>This doesn't say you can't mark media packets in some way
> > that sends
> > >>them down some specific tunnels.
> >
> > >The process of doing this -- routing by packet markings --
> > and how this
> > >will be setup on a call-by-call basis from the same IP address
pairs
> > >used for best efforts should be in scope.
> >
> > Now we may be getting somewhere.  This seems like it creates
> > requirements I might be able to deal with.
> >
> > What I'm hearing is that you think, fundamentally, that
> > signaling packets must be able to be marked differently from
> > media packets.  Seems hard to argue with that.
> >
> > But I believe you want a requirement that we cover PER FLOW
> > marking.  I think that might be something worth discussing.
> >
> > There are two ways we know how to do this.  The right way
> > (get the origin to mark them right in the first place) and
> > the expeditious way (put an intermediary in the path and
> > remark them).  That intermediary could be an
> > L5/L7 entity, or it could be down in router-land using normal
> > flow identifier techniques.
> >
> > Are you looking for requirements like that?
> >
> >
> >
> >
> >
> > >>This doesn't say you can't create any kind of static routing
> > >>mechanisms
> > you
> > >>like for any set of flows you can identify.
> >
> > >Once again....how to use these static routes (which is often
> > why SBC's
> > >are used--essentially creating the head of a static route)
> > needs to be
> > >studied by this group.
> > Well, is this any different from the marking issue above?
> > What do you want the BCP to say beyond marking of packets?
> > What is the requirement?
> >
> > Marking of packets is a subject worthy of discussion I think.
> >
> > In the best of all worlds, we would agree on the proper
> > marking of packets, all networks would mark in a uniform way,
> > and routers would route in an optimal manner for the packets
> > marked appropriately no matter how many domains the packets crossed.
> >
> > Dream on you say.
> >
> > I agree, but we should, probably, at least mention the ideal
> > (which implies we actually specify what the marking should
> > be).  I'd expect to see signaling packets marked differently
> > than media packets.  There could reasonably be different
> > marking for different kinds of media (text vs audio vs video,
> > for example).
> >
> > Then we have to deal with the reality that marking within a
> > domain may be consistent, but in peering, the O marking won't
> > be the same as the T marking, and we need to remark at the
> > peering edge.
> >
> > Then we could consider per-flow marking.  I'm not so sure I
> > want to go there, but I'm willing to listen.
> >
> > But is there more than that?  What, exactly?
> >
> > Brian
> >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "James McEachern" <[email-masked]>
Date: Tue, 11 Apr 2006 12:05:44 -0400

Comments inline.

> Sent: Monday, April 10, 2006 3:45 PM
> Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs
> peering
> 
> document that as "Best Current Practice".  In the absence of anything like

[JMcE] If we have per T-domain marking and DiffServ, then presumably we must have a policy that specifies the translation for each O-T pair.  If we agree on this, then does it really matter if that "per O-T translation policy" has a single entry, an entry per media type, or multiple options per media type?  If fact, once we allow for such translation, do we even need to specify how many options are possible?
 
> Subject: RE: [Speermint] RE: BackgroundReadingonNGNInterconnect-transitvs
> peering
> 
> 
> Brian,
> 
> borders -- and across trust boundaries. What we really need to solve the
> routing problem is a second forwarding equivalence class -- one for best
> efforts, and one for voice. These must be advertised through BGP4 edges to
> effect a second routing plane. Only then can you solve the routing problem.
> 
> on service (different next-hop networks), we have solved a first problem.
> However it is unclear that we have made the internet better. Now when you
> "ping" an address, you get a different response if the ToS is best efforts
> "unreachable address messages" to take into account the ToS. There may be
> many other protocol issues that occur when these bits are not set properly.
> 
> I want to establish a TCP/TLS SIPS session to a proxy. This proxy is ONLY
> doesn't have the ToS bits set yet (since I can't do a SOCKOPTS until the
> socket is opened). Thus we would have to alter the ways Berkely sockets
> work
> These complications may be worth the salvation of honor and avoidance of
> Uh-huh, at least for a generic "everyone should do this" kind of thing.
> 
> I have no illusions that big complex carrier networks will adopt anything
> as
> straightforward as -service-classes, but many more focused carriers could,
> and profit there-by.
> 
> sufficient.  We probably need some kind of policy driven re-marking thingy.
> 
> What I'm not so sure about is PER FLOW decision making.  PER "T-NETWORK"
> is
> maybe doable.
> 
> Brian
> 
> > >The process of getting signaled RTP data onto these tunnels, and not
> > >will be setup on a call-by-call basis from the same IP address pairs

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Apr 2006 15:43:18 -0400

Yes, well we aren't doing a good job of separating our terms, and transit
networks are indeed a fact of life.

So, yes, I think it's the peering destination network, which would be
"next-hop" at the peering point who would have a marking policy.

We could define this away by saying it was that network who was responsible
for marking its packets any way in wants on entry, rather than the peering
"network"'s responsibility.

I don't think we need an O-T pair; I think we need a T (or as Tim says, next
hop) policy.  Every flow to that next hop gets marked the way that network
wants it.  Source doesn't matter.

IN THE PEERING FABRIC, I think it probably doesn't matter; I think you can
probably do admission control into the fabric that makes diffserv within the
fabric unnecessary.  If you did want it, then you have to remark on entrance
to the fabric with the fabric's code points, and then remark again with the
next hop network's desired codepoints.

Brian

-----Original Message-----
From: Tim Dwight [mailto:[email-masked]] 
Sent: Tuesday, April 11, 2006 12:11 PM
To: 'James McEachern'; [email-masked]; 'Patrick Melampy';
[email-masked]

Wouldn't the marking need to be per the requirements of the adjacent network
rather than the network in which the session terminates?  We are talking
about L3 markings and there may be multiple L3 networks between O and T.

Tim

-----Original Message-----
From: James McEachern [mailto:[email-masked]] 
Sent: Tuesday, April 11, 2006 11:06 AM
To: [email-masked]; Patrick Melampy; [email-masked]
Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs
peering

Comments inline.

> good reports on complexity, stability and usefulness, then maybe we 
> could document that as "Best Current Practice".  In the absence of 
> anything like it, to my knowledge, in the wild, I'd say let's not go 
> there.
> 
> result in a "more bandwidth is cheaper" conclusion, but since my 
> speculation isn't any more valid that yours I think we just 
> fagetabodit.
> 

[JMcE] If we have per T-domain marking and DiffServ, then presumably we must
have a policy that specifies the translation for each O-T pair.  If we agree
on this, then does it really matter if that "per O-T translation policy" has
a single entry, an entry per media type, or multiple options per media type?
If fact, once we allow for such translation, do we even need to specify how
many options are possible?
 
> the routing problem is a second forwarding equivalence class -- one 
> for best efforts, and one for voice. These must be advertised through 
> BGP4 edges to effect a second routing plane. Only then can you solve the
routing problem.
> based on service (different next-hop networks), we have solved a first 
> problem.
> you "ping" an address, you get a different response if the ToS is best 
> efforts verses Voice. You also would have to revise ICMP handling to 
> deal with "unreachable address messages" to take into account the ToS. 
> There may be many other protocol issues that occur when these bits are not
set properly.
> ONLY reachable in the ToS Voice forwarding plane. However, when I use 
> the Berkely Sockets to create the socket ... the syn/syn syn/ack ack 
> three way handshake doesn't have the ToS bits set yet (since I can't 
> do a SOCKOPTS until the socket is opened). Thus we would have to alter 
> the ways Berkely sockets work to ensure that the 3way TCP handshake 
> routes properly.
> 
> of doing something evil like a simple NAT like SBC's do.
> 
> anything as straightforward as -service-classes, but many more focused 
> carriers could, and profit there-by.
> 
thingy.
> Reading onNGNInterconnect-transitvs peering
> 
> Brian,
> 
> > >not the best efforts packets from the same IP address pairs, is
> > essential
> > >and in scope.
> >
> > ....
> >
> > >pairs used for best efforts should be in scope.
> >
> > What I'm hearing is that you think, fundamentally, that signaling 
> > packets must be able to be marked differently from media packets.  
> > Seems hard to argue with that.
> >
> > But I believe you want a requirement that we cover PER FLOW marking.  
> > I think that might be something worth discussing.
> >
> > There are two ways we know how to do this.  The right way (get the 
> > origin to mark them right in the first place) and the expeditious 
> > way (put an intermediary in the path and remark them).  That 
> > intermediary could be an
> > L5/L7 entity, or it could be down in router-land using normal flow 
> > identifier techniques.
> >
> > In the best of all worlds, we would agree on the proper marking of 
> > packets, all networks would mark in a uniform way, and routers would 
> > route in an optimal manner for the packets marked appropriately no 
> > matter how many domains the packets crossed.
> >
> > Dream on you say.
> >
> > I agree, but we should, probably, at least mention the ideal (which 
> > implies we actually specify what the marking should be).  I'd expect 
> > to see signaling packets marked differently than media packets.  
> > There could reasonably be different marking for different kinds of 
> > media (text vs audio vs video, for example).
> >
> > Then we have to deal with the reality that marking within a domain 
> > may be consistent, but in peering, the O marking won't be the same 
> > as the T marking, and we need to remark at the peering edge.
> >
> > Then we could consider per-flow marking.  I'm not so sure I want to 
> > go there, but I'm willing to listen.
> >

---

From: "James McEachern" <[email-masked]>
Date: Wed, 12 Apr 2006 11:22:32 -0400

Brian,
We may need a picture, but I'm afraid these didn't help - I'm more confused than I was when I started.  I think I must be missing something, so I'll state my assumptions here, and perhaps someone can point out where I have gone astray.

My assumptions:
1. The O network is using DiffServ markings within its network.
2. The T network is using DiffServ markings within its network, but they are not the same markings as in the O network.  
3. The peering point is carrying more than one media type, and the media types do not all have the same DiffServ markings. 
4. Therefore, it is not possible for the T network to determine a priori the appropriate DiffServ markings (and apply them to all the traffic) simply on the basis of the peering point.  The T network must look at the media-specific markings for each media type, and translate those to the corresponding media-specific marking that it uses for that media type in its network.  Since each network (potentially) uses a different marking scheme, this results in mappings for each O-T pair.  This should apply no matter where the marking is applied.

What am I missing?

Jim

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 12, 2006 9:49 AM
To: McEachern, James [CAR:5N00:EXCH]; [email-masked]; 'Patrick Melampy'; [email-masked]
Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering

Jim

Need a picture:

O ---- P ---- T
         ^

You mark at the exit of the peering fabric with the T marking (where T here
is either the terminating network or the transit network as Tim suggests).

You could mark on entrance, but then, as you suggest, you would have O-T
pairs.
O ---- P ---- T
 ^

Of course, as I pointed out, there are two sides to the exit (and entrance).
If the peering system does the marking, it's in scope. 
O ---- P ---- T
         ^ 
If the T network does its own marking on its entrance:
O ---- P ---- T
             ^
then its out of scope.

If it's done on entrance, than it's in scope.
O ---- P ---- T
      ^
Or
O ---- P ---- T
 ^

If it's done on entrance with T's marking, then the peering fabric can't use
markings (can't implement DiffServ).  As I said, this may not be a problem.
If it's done on entrance with P's marking, and again on exit with T's:
O ---- P ---- T
  ^
  P
         ^
         T

then you can use diffserv in the fabric

Brian

-----Original Message-----
From: James McEachern [mailto:[email-masked]] 
Sent: Tuesday, April 11, 2006 5:51 PM
To: [email-masked]; [email-masked]; Patrick Melampy;
[email-masked]

Brian,
Perhaps it is just an issue of terminology, but if an "originating" network
knows how to map from its internal marking to something appropriate for each
"peering destination network", and every other originating network has a
similar mapping for each of its peering destination networks, then in
aggregate we have a mapping for every O-T (or O-D) pair.

Jim

> Sent: Tuesday, April 11, 2006 3:43 PM
> To: [email-masked]; McEachern, James [CAR:5N00:EXCH]; 'Patrick
> Melampy'; [email-masked]

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 12 Apr 2006 11:47:54 -0400

James,

Let us say that network A uses markings A1, A2, A3 for voice, video, and
data internally.
Let us say that network B uses markings B1, B2, B3 ...
...

Assume we want to allow each network operator to assign them
independently.
This leads to many, many permutations.

Now, let us say that for handoff at a peering point, 
we standardize markings P1, P2, and P3 ...

We now have:
A1 -> P1 -> B1
A2 -> P2 -> B2
A3 -> P3 -> B3

The mapping is always to/from the internal to the standard.  Each
operator only needs to know how to map from their Ax assignments to the
standard Px assignments.  That was my understanding of the problem and
solution.  But, perhaps there is more to it.

Mike

> Sent: Wednesday, April 12, 2006 11:23 AM
> To: [email-masked]; [email-masked]; Patrick 
> Melampy; [email-masked]
> Subject: RE: [Speermint] 
> RE:BackgroundReadingonNGNInterconnect-transitvs peering
> 
> Brian,
> We may need a picture, but I'm afraid these didn't help - I'm 
> more confused than I was when I started.  I think I must be 
> missing something, so I'll state my assumptions here, and 
> perhaps someone can point out where I have gone astray.
> 
> My assumptions:
> 2. The T network is using DiffServ markings within its 
> network, but they are not the same markings as in the O network.  
> 3. The peering point is carrying more than one media type, 
> and the media types do not all have the same DiffServ markings. 
> 4. Therefore, it is not possible for the T network to 
> determine a priori the appropriate DiffServ markings (and 
> apply them to all the traffic) simply on the basis of the 
> peering point.  The T network must look at the media-specific 
> markings for each media type, and translate those to the 
> corresponding media-specific marking that it uses for that 
> media type in its network.  Since each network (potentially) 
> uses a different marking scheme, this results in mappings for 
> each O-T pair.  This should apply no matter where the marking 
> is applied.
> 
> What am I missing?
> 
> Jim
> 
> To: McEachern, James [CAR:5N00:EXCH]; 
> [email-masked]; 'Patrick Melampy'; [email-masked]
> Subject: RE: [Speermint] 
> RE:BackgroundReadingonNGNInterconnect-transitvs peering
> 
> Jim
> 
> Need a picture:
> 
> 
> O ---- P ---- T
>          ^
> 
> You mark at the exit of the peering fabric with the T marking 
> (where T here is either the terminating network or the 
> transit network as Tim suggests).
> 
> You could mark on entrance, but then, as you suggest, you 
> would have O-T pairs.
> O ---- P ---- T
>  ^
> 
> If it's done on entrance with T's marking, then the peering 
> fabric can't use markings (can't implement DiffServ).  As I 
> said, this may not be a problem.
> To: [email-masked]; [email-masked]; Patrick 
> Melampy; [email-masked]
> Subject: RE: [Speermint] 
> Perhaps it is just an issue of terminology, but if an 
> "originating" network knows how to map from its internal 
> marking to something appropriate for each "peering 
> destination network", and every other originating network has 
> a similar mapping for each of its peering destination 
> networks, then in aggregate we have a mapping for every O-T 
> (or O-D) pair.
> 
> Jim
> 
> > To: [email-masked]; McEachern, James [CAR:5N00:EXCH]; 
> > 'Patrick Melampy'; [email-masked]
> > Subject: RE: [Speermint] 
> > Yes, well we aren't doing a good job of separating our terms, and 
> > transit networks are indeed a fact of life.
> > 
> > We could define this away by saying it was that network who was 
> > responsible for marking its packets any way in wants on 
> entry, rather 
> > than the peering "network"'s responsibility.
> > 
> > hop) policy.  Every flow to that next hop gets marked the way that 
> > network wants it.  Source doesn't matter.
> > 
> > IN THE PEERING FABRIC, I think it probably doesn't matter; 
> I think you 
> > can probably do admission control into the fabric that 
> makes diffserv 
> > within the fabric unnecessary.  If you did want it, then 
> you have to 
> > remark on entrance to the fabric with the fabric's code points, and 
> > then remark again with the next hop network's desired codepoints.
> > 
> > Brian
> > 
> > Wouldn't the marking need to be per the requirements of the 
> adjacent 
> > network rather than the network in which the session 
> terminates?  We 
> > are talking about L3 markings and there may be multiple L3 networks 
> > between O and T.
> > 
> > Tim
> > 
> > 
> > > If such things were deployed now, even experimentally, and we had 
> > > some good reports on complexity, stability and usefulness, then 
> > > maybe we could document that as "Best Current Practice".  In the 
> > > absence of anything like it, to my knowledge, in the 
> wild, I'd say 
> > > let's not go there.
> > >
> > [JMcE] If we have per T-domain marking and DiffServ, then 
> presumably 
> > we must have a policy that specifies the translation for each O-T 
> > pair.  If we agree on this, then does it really matter if that "per 
> > O-T translation policy"
> > has
> > a single entry, an entry per media type, or multiple 
> options per media 
> > type?
> > If fact, once we allow for such translation, do we even need to 
> > specify how many options are possible?
> > 
> > >
> > > Brian
> > >
> > > This new kind of policy driven marking thing must work across 
> > > network borders -- and across trust boundaries. What we 
> really need 
> > > to solve the routing problem is a second forwarding equivalence 
> > > class -- one for best efforts, and one for voice. These must be 
> > > advertised through
> > > BGP4 edges to effect a second routing plane. Only then 
> can you solve 
> > > the
> > routing problem.
> > >
> > > If this was all completed, and we could make packets route 
> > > differently based on service (different next-hop 
> networks), we have 
> > > solved a first problem.
> > > However it is unclear that we have made the internet better. Now 
> > > when you "ping" an address, you get a different response 
> if the ToS 
> > > is best efforts verses Voice. You also would have to revise ICMP 
> > > handling to deal with "unreachable address messages" to 
> take into account the ToS.
> > > There may be many other protocol issues that occur when 
> these bits 
> > > are
> > not
> > set properly.
> > >
> > > ONLY reachable in the ToS Voice forwarding plane. However, when I 
> > > use the Berkely Sockets to create the socket ... the 
> syn/syn syn/ack 
> > > ack three way handshake doesn't have the ToS bits set yet 
> (since I 
> > > can't do a SOCKOPTS until the socket is opened). Thus we 
> would have 
> > > to alter the ways Berkely sockets work to ensure that the 
> 3way TCP 
> > > handshake routes properly.
> > >
> > > These complications may be worth the salvation of honor and 
> > > avoidance of doing something evil like a simple NAT like SBC's do.
> > >
> > > Subject: RE: Media Packet Marking, was RE: [Speermint] RE: 
> > > Background ReadingonNGNInterconnect-transitvs peering
> > >
> > > anything as straightforward as -service-classes, but many more 
> > > focused carriers could, and profit there-by.
> > >
> > > So, I think our BCP should reference that work, but I 
> believe it's 
> > > not sufficient.  We probably need some kind of policy driven 
> > > re-marking
> > thingy.
> > >
> Background 
> > > > I changed the subject line, at least this part of the 
> thread may 
> > > > be
> > > > fruitful>
> > > >
> > > >
> signaling 
> marking of 
> > > > packets, all networks would mark in a uniform way, and routers 
> > > > would route in an optimal manner for the packets marked 
> > > > appropriately no matter how many domains the packets crossed.
> > > >
> > > > Dream on you say.
> > > >
> > > > (which implies we actually specify what the marking 
> should be).  
> > > > I'd expect to see signaling packets marked differently 
> than media packets.
> > > > Then we could consider per-flow marking.  I'm not so 
> sure I want 
> > > > to go there, but I'm willing to listen.
> > > >

---

From: "James McEachern" <[email-masked]>
Date: Wed, 12 Apr 2006 13:45:36 -0400

Thanks - I think I finally understand.

My question now, is whether this is in scope for the initial SPEERMINT deliverables, or part of the second wave?  (Reading the charter again, my initial suspicion is second wave, but I'm just asking...)

Jim 

-----Original Message-----
From: Tim Dwight [mailto:[email-masked]] 
Sent: Wednesday, April 12, 2006 12:19 PM
To: 'Michael Hammer (mhammer)'; McEachern, James [CAR:5N00:EXCH]; [email-masked]; 'Patrick Melampy'; [email-masked]
Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering

I think this is becoming more realistic, let's extend on it a little.  

Suppose there is as Mike suggests, a standard that says voice, video and
data map to DSCPs P1, P2 and P3 at inter-network interfaces.  Suppose
further you have networks A, B and C which pass traffic at L3 serially, as
follows:

    A | <---L3---> | B | <---L3---> | C

Within network A these services are mapped to DSCPs A1, A2 and A3.  Within
network B they are mapped to DSCPs to B1, B2 and B3.  Within network C they
are mapped to DSCPs C1, C2 and C3.  I believe the expectation at
inter-network boundaries is that the sending network maps the traffic per
the "standard".  Which means that each operator can reliably interpret the
arriving traffic, mapping it to its internal mappings if desired, then
mapping it back to the "standard" before handing it to the next operator.

There is of course the potential to lose granularity in this mapping
process.  For example network B might map P1 and P2 both to EF.  At the
interface to C there's no easy way for it to reverse this.  Which can lead
to a sort of "QoS inflation", assuming that in this example network B would
map EF to P1.  There are commercial implications to its doing so, which are
WAY outside the scope of this WG but that would in practice mitigate such
practice (i.e., the simplest thing to do is to maintain the granularity
implied by the standard markings).  

tim

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Wednesday, April 12, 2006 10:48 AM
To: James McEachern; [email-masked]; [email-masked]; Patrick

James,

Assume we want to allow each network operator to assign them independently.
This leads to many, many permutations.

Now, let us say that for handoff at a peering point, we standardize markings
P1, P2, and P3 ...

We now have:
A1 -> P1 -> B1
A2 -> P2 -> B2
A3 -> P3 -> B3

The mapping is always to/from the internal to the standard.  Each operator
only needs to know how to map from their Ax assignments to the standard Px
assignments.  That was my understanding of the problem and solution.  But,
perhaps there is more to it.

Mike

> We may need a picture, but I'm afraid these didn't help - I'm more 
> confused than I was when I started.  I think I must be missing 
> something, so I'll state my assumptions here, and perhaps someone can 
> point out where I have gone astray.
> 
> My assumptions:
> 2. The T network is using DiffServ markings within its network, but 
> they are not the same markings as in the O network.
> 3. The peering point is carrying more than one media type, and the 
> media types do not all have the same DiffServ markings.
> 4. Therefore, it is not possible for the T network to determine a 
> priori the appropriate DiffServ markings (and apply them to all the 
> traffic) simply on the basis of the peering point.  The T network must 
> look at the media-specific markings for each media type, and translate 
> those to the corresponding media-specific marking that it uses for 
> that media type in its network.  Since each network (potentially) uses 
> a different marking scheme, this results in mappings for each O-T 
> pair.  This should apply no matter where the marking is applied.
> 
> What am I missing?
> 
> Jim
> 
> You mark at the exit of the peering fabric with the T marking (where T 
> here is either the terminating network or the transit network as Tim 
> suggests).
> 
> You could mark on entrance, but then, as you suggest, you would have 
> O-T pairs.
> O ---- P ---- T
>  ^
> 
> If it's done on entrance with T's marking, then the peering fabric 
> can't use markings (can't implement DiffServ).  As I said, this may 
> not be a problem.
> Perhaps it is just an issue of terminology, but if an "originating" 
> network knows how to map from its internal marking to something 
> appropriate for each "peering destination network", and every other 
> originating network has a similar mapping for each of its peering 
> destination networks, then in aggregate we have a mapping for every 
> O-T (or O-D) pair.
> 
> Jim
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 13 Apr 2006 14:26:27 -0400

I think this is what I was just asking in my last post Mike, sounds like
we're thinking the same thing on this question.  

Jason  

> Sent: Wednesday, April 12, 2006 11:48 AM
> To: James McEachern; [email-masked]; 
> [email-masked]; Patrick Melampy; [email-masked]
> Subject: RE: [Speermint] 
> Let us say that network A uses markings A1, A2, A3 for voice, 
> video, and data internally.
> Now, let us say that for handoff at a peering point, we 
> standardize markings P1, P2, and P3 ...
> 
> We now have:
> A1 -> P1 -> B1
> A2 -> P2 -> B2
> A3 -> P3 -> B3
> 
> The mapping is always to/from the internal to the standard.  
> Each operator only needs to know how to map from their Ax 
> assignments to the standard Px assignments.  That was my 
> understanding of the problem and solution.  But, perhaps 
> there is more to it.
> 
> Mike
> 
> 
> 
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 13 Apr 2006 14:28:57 -0400

> If such things were deployed now, even experimentally, and we 
> had some good reports on complexity, stability and 
> usefulness, then maybe we could document that as "Best 
> Current Practice".  In the absence of anything like it, to my 
> knowledge, in the wild, I'd say let's not go there.

I know some of the North American MSOs have had a trial going for awhile
and have gone through a few iterations.  Perhaps some of them will
consider submitting an I-D for the WG to understand the iterations
they've evolved through and share some knowledge in a structured manner.
Some of those learnings could be helpful to our work and discussions
here.  I'd encourage any other active trials to consider doing the same,
for what its worth.

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 13 Apr 2006 14:28:57 -0400

So are you saying that there should be some commonly agreed DSCP marking
values where domains peer, and each domain is then responsible for
translating those values to whatever is used (if different) inside their
own network?

Jason