Subject: UDP questions

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 3 Aug 2004 06:09:19 +0300

Following my presentation today,
I would like to solicit responses to the 2 questions I raised.

1) Should the PW label be placed in
    A) destination UDP port field (has NAT/firewall issues)
    B) source UDP port     ?

2) What label distribution should be used 
    A) implicit upstream (has security considerations)
    B) standard LDP-based PWE protocol
    C) other     ?

Y(J)S

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

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 3 Aug 2004 19:18:37 +0300

Yakov, 

We have already had this discussion,
with Eric asking this question.

The main reasons for allowing this are:

1) it is already widely employed for TDM PWs
2) it is arguably the first PW technique
3) it aligns with avt work
4) it is in the charter
5) it is in the arcitecture document.

So if we find strong reasons AGAINST its use,
then I can understand our considering prohibiting it.
But wouldn't any such reason would impact avt work as well?

Y(J)S

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]] 
> Sent: Tuesday, August 03, 2004 17:38
> To: Yaakov Stein
> Cc: [email-masked]
> Subject: Re: [PWE3] UDP questions 
> 
> Yaakov,
> 
> Should the PW label be placed in the UDP header in the first place ?
> 
> Yakov.
> 
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 3 Aug 2004 19:34:04 +0200

Yaakov,
Please see a brief comment inline.

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Tuesday, August 03, 2004 6:19 PM
> To: Yakov Rekhter
> Cc: [email-masked]
> Subject: RE: [PWE3] UDP questions 
> 
> 
> Yakov, 
> 
[Sasha] If this is the reason, then the answer to the rest of the
questions seems obvious, as this reason only makes sense if
the UDP ports are used in an AVT-compliant way.

And this is OK with me.

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 3 Aug 2004 19:38:37 +0300

Ron, 
 
Sorry you couldn't make it to San Diego.
 
Do you have a solution to the NAT/firewall issues
that arise when using destination UDP field ?
 
Y(J)S

________________________________

	From: Ron Cohen [mailto:[email-masked]] 
	Sent: Tuesday, August 03, 2004 19:34
	To: Yaakov Stein; [email-masked]
	Subject: RE: [PWE3] UDP questions

	Yaakov,
	 
	My input:
	 
	1. Destination UDP port should be the multiplexer
	2. Don't know
	 
	Thanks
	Ron

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Yaakov Stein
		Sent: Monday, August 02, 2004 8:09 PM
		To: [email-masked]
		Subject: [PWE3] UDP questions

		I would like to solicit responses to the 2 questions I
raised.

		    A) destination UDP port field (has NAT/firewall
issues)

		    B) source UDP port     ?

		    C) other     ?

		Y(J)S

---

From: Scott W Brim <[email-masked]>
Date: Tue, 3 Aug 2004 09:40:44 -0700

> > >     A) destination UDP port field (has NAT/firewall issues)

If it's already widely deployed, we can go with the format that is
dominant in real networks?

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 3 Aug 2004 19:42:28 +0300

> [Sasha] If this is the reason, then the answer to the rest of 
> the questions seems obvious, as this reason only makes sense 
> if the UDP ports are used in an AVT-compliant way.
> 
> And this is OK with me.

Sasha, 

This is certainly a complelling argument.

Unfortunately, as I am sure you know,
VoIP has terrible problems with getting through
firewalls. I can't use VoIP from my office PC.

Skype and others are having tremendous success
with alternative protocols, precisely because
they can get around this issue.

So why repeat this fiasco and have someone
come up with a non-PWE-sanctioned protocol
and capture the market claiming it is better
for this reason?

Y(J)S

---

From: Eric Rosen <[email-masked]>
Date: Tue, 03 Aug 2004 13:11:08 -0400

I am still opposed  to this use of UDP and would like  to see a WG consensus
before we respond positively to the ITU-T liaison.  

However,  if one  were  going to  use  one of  the UDP  port  fields for  PW
multiplexing, the only things that makes any sense to me is using the source
port field, with a well known value in the destination port field. 

Of  course,  since  there  is  no  signaling to  support  the  use  of  this
encapsulation, I don't  really see the point.  If L2TP  cannot be used, then
MPLS-in-GRE would  seem to  be the  best thing.  One  advantage is  that the
security section for it has already been written.

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 3 Aug 2004 10:12:17 -0700

Yaakov,
 
>that arise when using destination UDP field ?
 
1. No
2. Have the same solution as VoIP or whatever else
3. It is out of the scope of PWE3 charter (or at least I hope it is)
4. Per spec UDP dest port is the multiplexer that selects the
process/socket on the destination system. If the suggestion is to use
src port as multiplexer I would prefer not to have UDP option for PWE3
at all. 
 
Cheers
Ron

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2004 9:39 AM
To: Ron Cohen; [email-masked]
Subject: RE: [PWE3] UDP questions

Ron, 

 
Y(J)S

  _____  

Yaakov,
 
My input:

Thanks
Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaakov Stein
Sent: Monday, August 02, 2004 8:09 PM
To: [email-masked]
Subject: [PWE3] UDP questions

    B) source UDP port     ?

    C) other     ?

Y(J)S

---

From: [email-masked]
Date: Wed, 4 Aug 2004 09:14:09 +0100

Yaakov,

With all due respect I don't find your arguments compelling....in 1-5
below only 3 offers an 'argument', the rest are simply statements of
'this is what we are doing' (whether right or wrong).

Let me briefly re-state my take on this topic:
-	UDP (and TCP) are application adaptation functions, ie they
adapt applications to the layer network they will run on, here IP.
-	This is quite different to 'inter-layer client/server
adaptation' between 2 layer networks.....and the nature of the
adaptation required varies as a function of the mode/technology of both
the client and the server.  1 size does not fit all here.
-	Voice (or video) say is an application.  It is not a PDH E1
layer network entity.  It is not an SDH VC4 layer network enity.  Voice
is not 'TDM' either....in fact its pretty bursty.  Sure it has timing
requirements that must be satisfied, but these are not the same as those
for a proper TDM layer network.  TDM layer networks also require fault
management and performance management that is not the same (obviously!)
to a voice application.  I therefore conclude that the AVT argument is
not appropriate either.

So I don't regard UDP as an appropriate inter-layer adaptation function
for the carriage of co-cs mode layer networks (or indeed any mode layer
networks).

And I assume you would not be advocating this as a 'solution' anyway for
large operators or the Internet.....I guess this is targeted at
enterprises right?

Regards, Neil

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yaakov Stein
> Sent: 03 August 2004 17:19
> To: Yakov Rekhter
> Cc: [email-masked]

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 5 Aug 2004 00:28:17 +0300

Neil, 

The use of UDP/IP is one of the two methods for CE to CE PWs
(the other being the "naked inner label" method I described
in the past).  So, yes, this is for the enterprise space.

Regarding the "voice" vs TDM argument.
If your problem is OAM and timing recovery, 
I am willing to discuss these issues.
I don't see that the OAM issues are that much different
than for LDP MPLS PSNs, as these presently stand
(and you yourself have discussed this at great length 
in the past on this very list).
The timing recovery problem depends on packet-loss
rates and PDV, these are not directly dependent on
whether we have UDP/IP or MPLS (unless we have
some TE in the MPLS case, or RSVP in the UDP/IP case).

Y(J)S 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, August 04, 2004 11:14
> To: Yaakov Stein; [email-masked]
> Cc: [email-masked]
> With all due respect I don't find your arguments 
> compelling....in 1-5 below only 3 offers an 'argument', the 
> rest are simply statements of 'this is what we are doing' 
> (whether right or wrong).
> 
> adaptation' between 2 layer networks.....and the nature of 
> the adaptation required varies as a function of the 
> mode/technology of both the client and the server.  1 size 
> does not fit all here.
> layer network entity.  It is not an SDH VC4 layer network 
> enity.  Voice is not 'TDM' either....in fact its pretty 
> bursty.  Sure it has timing requirements that must be 
> satisfied, but these are not the same as those for a proper 
> TDM layer network.  TDM layer networks also require fault 
> management and performance management that is not the same 
> (obviously!) to a voice application.  I therefore conclude 
> that the AVT argument is not appropriate either.
> 
> So I don't regard UDP as an appropriate inter-layer 
> adaptation function for the carriage of co-cs mode layer 
> networks (or indeed any mode layer networks).
> 
> And I assume you would not be advocating this as a 'solution' 
> anyway for large operators or the Internet.....I guess this 
> is targeted at enterprises right?
> 
> Regards, Neil
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Yaakov Stein
> > So if we find strong reasons AGAINST its use, then I can understand 
> > our considering prohibiting it.

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 5 Aug 2004 02:19:23 +0200

Yaakov and all,
Please see some comments/answers inline.

> Sent: Tuesday, August 03, 2004 8:42 AM
> To: Sasha Vainshtein
> Cc: [email-masked]; Yakov Rekhter
[Sasha] Actually I only wanted to say that you cannot have it
both ways: claim VoIP and other RTP applications as justification
for having UDP-based PWs, AND promote a method that is
absolutely different from what these applications consistently use.
> they can get around this issue.
[Sasha] The following text is quoted verbatim (with only Q: and A: 
inserted for clarity)from the official Skype FAQ/Technical page 
(http://www.skype.com/help_faq.html#Technical)

<quote>
Q: I can't connect to Skype from work or due to a restrictive firewall. 
   Which ports need to be opened in order to use Skype? 

A: If you aren't familiar with firewalls or ports, 
   it may be a good idea to ask a system administrator 
   or tech-savvy friend to help you. The minimum requirement is that Skype 
   needs unrestricted outgoing TCP access to all destination ports above
1024 
   or to port 80 (the former is better, however). 
   If you don't allow either of those, Skype will not work reliably at all. 
   Voice quality and some other aspects of Skype functionality will be 
   greatly improved if you also open up outgoing UDP traffic to all 
   ports above 1024, and allow UDP replies to come back in. 
   In the quest for even better voice quality, it is also advisable 
   to open up incoming TCP and/or UDP to the specific port you see in 
   Skype Options. This port is chosen randomly when you install Skype. 
   In the case of firewalls, this should be easy to arrange. 
   In some routers, however, you cannot configure incoming UDP 
   at all (but you still can configure incoming TCP port forwarding, 
   which you could/should do). 
   The randomness in port selection is to improve NAT traversal 
   for cases where several users are behind the same NAT; 
   if they all used same ports, many NATs would behave in a way 
   that would reduce Skype voice quality. 
<end quote> 

An additional reference (http://www.skype.com/help_firewalls.html)
explicitly states that

<quote>
   Ideally, outgoing TCP connections to all ports (1..65535) 
   should be opened. This option results in Skype working most reliably.
<end quote>

So it seems to me that your reference to Skype as being free
from the firewall/NAT traversal problems is not correct.

> and capture the market claiming it is better
[Sasha] I am afraid that any FREE product (like Skype) has
a very good chance to capture the market regardless of
its being sanctioned or not sanctioned by any SDO.
This fact cannot, IMO, attest to the quality of the product,
its ability to solve any problems etc.

---

From: Tony Li <[email-masked]>
Date: Wed, 4 Aug 2004 17:56:07 -0700

It may well be easier to get a different protocol that does NOT use  
ports through a
NAT/firewall device.  If nothing else, you will be quite certain that  
the NAT is not
messing with your demuxing.

Tony

p.s.  A de-facto standard that solves no problems is an oxymoron.  A  
de-facto
standard becomes established precisely because it is solving real world  
problems,
usually because the SDO is not doing so as rapidly as the market would  
like.
Pedal on the right, please.

---

From: [email-masked]
Date: Thu, 5 Aug 2004 11:01:00 +0100

Hi Yaakov,
> in the past).  So, yes, this is for the enterprise space.
NH=> That's my take.  Which is fine, but this is not a solution for the
operator community IMO, nor I think the Internet community (but I'll let
others ponder on that one).  And the operator community should think
long and hard on what this might mean for their current services that
operate in this space (but its bigger than this, and the efficiency
illusion of QoS and that '1 technology/mode can do it all' is also
wrapped up in this).  We should be careful of what the longer-term
implications of bad arch will be on future investment......take care not
to kill the industry on religious grounds or too much short-termism.
> I am willing to discuss these issues.
NH=> Well only partially....as I have maintained for a long time now,
from an operator's viewpoint it makes a great deal of sense to manage
the trails of a layer network in a consistent manner irrespective of the
client.....one does not want a plethora of solutions here that are
client specific.  (Your stuff is for sure operating in this space....but
I don't blame you for that, you are constrained by the foundations of
what you have been given...and it is these foundations that are the real
problem)  Rather obvious I think, but as soon as the BW squeezing
mind-set appears things start going pear-shaped here.....and again as I
have maintained, in any clinet/server layer network relationship client
layer transparency must be the default, not the special case.

> in the past on this very list).
NH=> But are the messages taken on board or are they ignored?  It sure
feels like the latter.  Maybe the messages will have more
clarity/relevance once the commercial realities bite a bit harder.  The
key technical issue for this particular facet is that the management of
LSPs in MPLS is not the same as the management of a cl-ps layer network
like IP, and neither is it the same as the management of a co-cs layer
network like SDH.  The transport defects in each mode are different for
a start (though they are generic per mode), and yes I have tried to
explain this as you note....and to summarise:

Mode		Defects

cl-ps		Breaks

co-cs		Breaks
		Swaps, but only between exactly alike entities

co-ps		Breaks
		Swaps between any entities
		Mismerges, with the following subcases
		-	A1->A2 mismerging into B1->B2, with A1->A2
traffic seemingly unaffected
		-	A1->A2 mismerging into B1->B2, with A1->A2
traffic broken
		-	A1->A2 self-mismerging back into A1->A2

So I'd like to be able to manage the MPLS layer network in a consistent
manner irrespective of its clients.....ditto the IP layer and ditto the
main SDH co-cs transport networks (though these are well-sorted already
as I am sure any operator will understand).  But its far bigger than
just the OAM functional component of each mode.  Here, for example, are
a set of high-level (largely commercially driven) requirements I'd like
to see any proposed arch tested against:

1.	For many reasons real networks will run at low loads over most
of their life. It is therefore essential that we can create consistently
meaningful services (both public and private) over a large range of load
points, ie a customer gets what they have paid for, not what someone
else has paid for.  Further, the 'perceived value' and pricing of a
service must be decoupled from the network resource (ie bandwidth) used.

2.	The sensitive internal control/management-plane protocols must
be completely secure from attack, and the network must remain secure and
stable under situations of extreme stress, ie serious failures.  It is
therefore almost a no-brainer requirement that such protocols must be
run OOB (Out-Of-Band) in relation to customer traffic wherever possible.
A key corollary of this is that the OAM used to monitor the integrity of
the traffic and detect/handle defects must be run In-Band.

3.	We must be able to differentiate 'urgency' from 'importance'
over all load points for both public and private traffic.  For example,
voice traffic is always 'urgent' (ie cannot tolerate large delay
impairments) but it may or may not be 'important'.  Indeed, a similar
argument can be applied to any application.

4.	The network must be 'designed for uncertainty', ie it must be
able to accommodate unforeseen traffic types/vectors.

5.	We need to stop doing stovepipes, ie selling a specific
technology (and its functions/features) as 'the service'.  The target
architecture must factor-in migration of current legacy networks, and,
by inference, requires a clear architectural understanding of both
client/server layer network interworking and peer-partition layer
network interworking (this is not the same as what some folks call
'service i/w' for good reasons).

If the proposed architecture cannot deleiver against these then I think
we are creating problems for the whole community over the long-term.
Well, that's my view anyway.

> some TE in the MPLS case, or RSVP in the UDP/IP case).
NH=> This is also a function of network load.  If we have to run a given
mode at rather low loads (the uncertainty increases as one moves from
co-cs->co-ps->cl-ps, but don't necssarily read this as a 'bad thing',
its the mapping of the right mode to the appropriate public/private
application service case that is key) *and* if we have not ensured the
above requirements can be met (esp item 1) we have some serious problems
looming IMO.  At some point SLAs will enter the equation....now we need
some agreed HRXs with both end-end and apportionment rules on objective
Net Perf metrics (not some woolly hand-waving notion of 'QoS' I see
mentioned from time to time).   Well, seems we can't even get the basic
stuff like the defects sorted here....so what chance this?  Another
message I am sure folks are sick of me saying now is that the client
layer inherits both the disjoint connectivity (2-dim entity) and network
performance (1-dim entity) of its server layer....and this recurses to
the duct.  I have some ideas for a next generation network architecture
that could work and meet the requirements noted above (and almost as a
by-product will probably give lowest capex/opex too).....but it requires
letting go of modal/technology religion and seeing how each mode can
work in concert.  I do not believe we are quite ready to embrace
this.....maybe the commercials need to hurt some more.  Keep going the
way we currently are, and this is not a question of 'if' IMO but
'when'.....for some 'when' has already arrived of course.

So Yaakov, I for sure don't want to beat-up on your particular patch
here......this is a symptom IMO and not the cause.  Its no good keep
addressing symptoms however, we need stand back and look at the total
picture to see what are the real problems.  The world is changing and
its no longer the old Telco world nor is it the pioneering/experimental
world that spawned the Internet.  We need to find solutions that
recognise this.  There are some 'discovered truths' about networking,
some folks might not like them, but we can't alter that.  What we can do
however, is look for the optimum way of marrying all the best bits from
what we have collectively learned to date.  Not to do so would be just
plain daft IMO.

Regards, Neil

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 5 Aug 2004 19:36:42 +0300

> Q: I can't connect to Skype from work or due to a restrictive 
> firewall. Which ports need to be opened in order to use Skype? 

This is some strange case.

Quoting from the Skype site :

  *Works with all firewall, NAT and routers - nothing to configure! 

and from the FAQ:

  Several new techniques were also developed in order to avoid end-user
configuration 
  of gateways and firewalls, whose non-intuitive configuration settings
typically prohibit 
  the majority of users from communicating successfully. 
  In short, Skype works behind the majority of firewalls and gateways
with no special configuration.

>From personal experience this is true.
In my organization I can get SIP-based VoIP 
to work from my desk, bur Skype works fine.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 5 Aug 2004 19:40:09 +0300

> It may well be easier to get a different protocol that does 
> NOT use ports through a NAT/firewall device.  If nothing 
> else, you will be quite certain that the NAT is not messing 
> with your demuxing.

As I have said before, there is no problem with
using UDP ports, just with using the DESTINATION port.

> p.s.  A de-facto standard that solves no problems is an 
> oxymoron.  A de-facto standard becomes established precisely 
> because it is solving real world problems, usually because 
> the SDO is not doing so as rapidly as the market would like.

Well, my presentation here at San Diego and
my email to the list were precisely to speed things up.

Y(J)S