Subject: RE: [Speermint] RE: Background ReadingonNGNInterconnect-transitvs peering

From: "Patrick Melampy" <[email-masked]>
Date: Sat, 8 Apr 2006 10:52:33 -0400

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Apr 2006 15:45:23 -0400

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?

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,

-----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

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

Brian,

Mike