RE: [PCN] comments on draft-ietf-pcn-architecture-02

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

Hi Phil

Thank you!
Please see comments regarding comment_3:

> > Comment_3:
> > In Section 3, page 29, you provide the below conclusion on the
> viewpoint
> > that admission control is always done by probing:
> > 
> > "The first point breaks Assumption 3 (aggregation) and hence means
> that
> > this viewpoint is out of scope of initial Charter of the PCN WG."
> > 
> > I do not agree with this conclusion, since I do not agree with the 
> > argumentation that the first point breaks Assumption 3
> 
> the "first point" is this:
> o  Simply admitting the new flow has a significant risk of leading to
>       overload, because the PCN-domain reaches out towards the end
>       terminals where link capacity is low.
> The link capacity is low means that adding a single flow to 
> the link can move it directly from no congestion to 
> overloaded [real queue grows significantly or overflows]. 
> This breaks the aggregation assumption. 

Georgios: yes, But if the link capacity is low and the admission
threshold/rate in an PCN-interior node 
is high (by configuration), how then a single flow can move the state in the
PCN_interior_node from 
no congestion to congestion? This means that the admission threshold/rate
should be doen properly such 
that such a situation will not occur!

Best regards,
Georgios




> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: donderdag 22 november 2007 11:30
> To: [e-mail]; [e-mail]
> Subject: RE: [PCN] comments on draft-ietf-pcn-architecture-02
> 
> Georgios,
> Thanks for the comments!
> 
> > Comment_1:
> Lars has answered.
>  
> > Comment_2:
> > Section 3.5:
> > You mention:
> >    "The following two assumptions apply if the PCN WG decides to
> encode
> >    PCN-marking in the ECN-field.
> > 
> >    o  It is assumed that PCN-nodes do not perform ECN, [RFC3168], on
> >       PCN-packets.
> > 
> >    o  If a packet that is part of a PCN-flow arrives at a 
> PCN-ingress-
> >       node with its CE (Congestion experienced) codepoint 
> set, then we
> >       assume that the PCN-ingress-node drops the packet.  After its
> >       initial Charter is complete, the WG may decide to work on a
> >       mechanism (such as through a signalling extension) 
> that enables
> >       ECN-marking to be carried transparently across the 
> PCN-domain."
> > 
> > If I understand the two above assumptions well, they say 
> that traffic 
> > that is arriving into the PCN domain and is end-to-end ECN 
> aware can 
> > only keep its end-to-end ECN semantics if it is tunnelled.
> > In my opinion this is one possible implementation. There 
> might also be 
> > other implementation.
> 
> Yes, I agree tunnelling would be one option, and that there 
> would be other implementations. Note the issue of how to 
> carry ECN-marking transparently across the PCN-domain is one 
> that the WG may look at after the initial Charter is done. 
> Note also, the if: "if the PCN WG decides to encode 
> PCN-marking in the ECN-field" [in the terms of your encoding 
> draft, this would include ECN+DSCP option]
> > I think that this assumption should refer to the requirements 
> > described in RFC 4774:
> > http://www.ietf.org/rfc/rfc4774.txt?number=4774
> > 
> > Please use the below paragraph instead the one that is given above:
> >   "The following two assumptions apply if the PCN WG 
> decides to encode
> >    PCN-marking in the ECN-field.
> > 
> >    o It is assumed that the requirements imposed by RFC 4774 are 
> > fulfilled."
> 
> Yes, I think we could add a ref to 4774 somewhere in the 
> draft, and this seems a good place to do so. Will add as a 
> 3rd bullet something like "the Milestone on 'Survey of 
> Encoding Choices' will consider the implications of [RFC4774]"
> 
> > 
> > -------------------
> > 
> > Comment_3:
> > In Section 3, page 29, you provide the below conclusion on the
> viewpoint
> > that admission control is always done by probing:
> > 
> > "The first point breaks Assumption 3 (aggregation) and hence means
> that
> > this viewpoint is out of scope of initial Charter of the PCN WG."
> > 
> > I do not agree with this conclusion, since I do not agree with the 
> > argumentation that the first point breaks Assumption 3
> 
> the "first point" is this:
> o  Simply admitting the new flow has a significant risk of leading to
>       overload, because the PCN-domain reaches out towards the end
>       terminals where link capacity is low.
> The link capacity is low means that adding a single flow to 
> the link can move it directly from no congestion to 
> overloaded [real queue grows significantly or overflows]. 
> This breaks the aggregation assumption. 
> Best wishes
> Phil/
> 




_______________________________________________
PCN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pcn