[PCN] Comments on HOSE edge behaviour discussion

["Georgios Karagiannis" <[e-mail]>]

 
Hi Steven, Hi all

The PCN HOSE edge behaviour draft minutes and my comments on them, are
listed below!

> o Hose Edge Behaviour
> draft-karagiannis-pcn-hose-edge-behaviour-00
> http://www.ietf.org/proceedings/09nov/slides/pcn-2.pdf

> Ronald in 't Velt presented slides on the HOSE edge behaviour.  The
marking 
> behaviour draft (draft-ietf-pcn-marking-behaviour-05) says that ETM-marked
> packets SHOULD be preferentially dropped - which is not what the HOSE edge
> behaviour wants.

> Lars Eggert: Can't update a standards-track document in an informational
edge
> behaviour document.

Georgios: Lars please note:
In Section 2.2 of
http://www.ietf.org/id/draft-ietf-pcn-marking-behaviour-05.txt is specified
that:

 o  PCN-packets that arrive at the PCN-node already excess-traffic-
      marked SHOULD be preferentially dropped;

In Appendix B4 is mentioned:

"The dropping behaviour is defined as a 'SHOULD', rather than a 'MUST', in
recognition that other dropping behaviour may be preferred in particular
circumstances, for example: (1) with the "marked flow" termination edge
behaviour, preferential dropping of unmarked packets may be better
[Menth09]; (2) tail dropping may make PCN-marking behaviour easier to
implement on current routers. Exactly what "preferentially dropped" means is
left to the implementation. It is also left to the implementation what to do
if there are no excess-traffic-marked PCN-packets available at a particular
instant."

The above emphasizes that in particular circummstances, preferential
dropping of unmarked packets should be possible. 
Such as circumstnace is specified in the HOSE edge behaviour draft.


> Philip Eardley: It seems dodgy to admit a flow if the signaling request is

> unmarked whatever the CLE.  This gives an incentive to send 1000s of
request
> repeatedly until one will get through.

Georgios: Phil, I do not understand the comment! Are you saying that QoS
signaling protocols, such as RSVP, 
cannot be used in such situations because no RSVP PATH messages will get
through? Please explain!

> Not many people have read the draft.

> Steven Blake: Need discussion on list before making this draft a working
group
> item, but the behaviour needs to work with the agreed marking behaviour
for
> ETM-marked packets.  I believe that it can probably can be made to work.

Georgios: I agree!

> Steven Blake: ECMP support - not safe to assume that path signaling
message
> will follow the same path as the data - so not safe to say that this
> scheme solves the ECMP support issue.

Georgios: Steve, please note that from the point of view of the followed 
communtication path for signaling messages and data packets, 
the same assumptions are used as the ones applied and used by RSVP PATH and
data packets.
Thus if the RSVP signaling works to support QOS, then the proposed ECMP
solution will also work.


> Francois le Faucher: Is it desirable that, in case the network is marking
50% 
> of packets, that we still accept 50% of new calls?

Georgios: Francois, I do not understand the comment, please elaborate!

> Steven Blake: Someone please send info to the mailing list.

> Bob Briscoe: Status update on the ECN tunnelling draft in tsvwg: thinks
issues
> have now been resolved, but thought this before.  Then 3-in-1 can go ahead
to
> last call, etc.

Best regards,
Georgios